all bits considered data to information to knowledge

4May/120

Adapting DbFit unit testing framework to team based environment

Introduction

There is a lot to be said about the virtue of simplicity. The unit testing frameworks out there could be daunting for uninitiated and many require to go through the hoops of additional technologies to get the job done. The xUnit derivatives such as JUnit or MSTest (and even more DB-specific adaptations such as dbUnit) require familiarity with the respective technologies – in addition to your database structures, code and data,. This is OK if you are using one of the ORM frameworks such as Hibernate, NHibernate, LINQ or Microsoft EF as you are writing Java or C# code anyway… but what if your database developers are so immersed into intricacies of SQL, Transact-SQL and PL/SQL that they do not have time to learn yet another language?
An interesting approach is offered by DbFit for Fitnesse… a wiki-based unit testing framework. Yes, you’ve heard this right – wiki-based. A test is written in a human readable markup language which is represented as a page in a Wiki website (the framework installation comes with embedded web server); upon test execution the wiki markup is passed to an engine that interprets and executes it against the code you want to test. The DbFit extension to the Fitness framework is unique in the sense that it does not require knowledge of Java or C#, and Wiki markup language’s conventions can be learned in but a couple of hours.
Getting started

So, what do you need to get started?

  1. Download full distribution of DbFit framework from Sourceforge . It includes all you need to run tests, no additional components are required – the framework, the web server, user manuals – it’s all in there.
  2. Unzip the contents of the package in the directory on your machine (both Windows and Linux environments are supported)
  3. Run start up script (startFitness.bat on Windows machines)

The webserver is java based so this is most likely picture you’d see after executing the script. Leave the window running, just minimize it (closing it would kill web server process, and the entire application)

The entire interface is web based, so you need to fire up your favorite browser and navigate to http://localhost:8085/ (note that by default the web server starts on port 8085, so you need to add this port to the address to access the page).

NB:The package also includes a comprehensive manual which takes you from the first steps to the mastery in but five chapters.
Now you are ready to run the batteries of the tests supplied with the framework… They come in two flavors: Java and .Net, your choice of either one will depend on personal preferences and the setup environment (i.e. you’ll be more likely to choose Java version if you are running a Linux machine). Click on [.Net Acceptance tests] link

The DbFit framework currently supports testing of Oracle, Microsoft SQL Server, IBM DB2 and MySQL testing though there are some limitations as to what you can test in each environment (e.g. currently, MySQL is not supported in .Net flavor). Here I have SQL Server 2008 Express edition set on my local machine - the same that I run dbFit.Fitnesse on, so let select [SQLServerTests] link

As you can see there are quite a few predefined test that you can modify for your environment (and you can add your own tests as wee - see manual for instructions).
Clicking on [Suite] button in the right pane would launch the battery of the tests you see in the Contents pane. But you are not quite ready yet - you still need to set up the connection string to your database; it could be shared through the entire series of test – or you could set up separate connection for each test. Select a test you’d like to rum ((here’s DateTests in my case), and click (Edit) link

Modify string to be a valid connection. For example: “!|Connect|.\SQLEXPRESS|fit|fit|library|” means : “coonect to local instance od SQLEXPRESS (.\SQLEXPRESS), user ID “fit”, password “fit”, database “library”.
Built-in tests are very good place to start with, and taking look into the already written tests would give a good idea about the syntax and structure of the markup scripts. You run the tests manually by clicking the [Test] button, and observe the results in the very same page (you can edit the test by clicking [Edit] button to the right; alternatively, yopu could import tests written in the markup in Microsoft Excel or Word formats). The results of the test are displayed in on the same page as it gets refreshed:

 

Running dbFit in team environment

The entire framework is conceived as personal productivity tool for individual developers, yet with a bit of tinkering it could be introduced into the team environment.

Here’s the setup that I came up with trying to solve problems of multi-user in wiki environment… First, all script pages need to be checked into version control (e.g. Subversion)

  1. Each developer has full DbFit/Fitnesse install on his/her workstation to run tests locally
  2. If applicable, each developer can run the tests against a local and/or dedicated database; if not – some thought needs to be given as to have to run tests in shared database environment – especially around security as database connection is embedded into the wiki pages and is unencrypted
  3. Since the team works in predominantly Windows/.Net environments we are using TortoiseSVN client to synchronize folders manually (it could also be automated)
  4. If unit tests history is required a process to harvest results’ files would have to be created (e.g. at the end of execution the results’ file gets transferred to version control repository, or gets renamed and time-stamped to prevents being overwritten; the files then can be parsed and trend graphs created)

This will give your developers a pretty good insight into formal quality of their code. Keep in mind that unit tests cannot vouch for validity of the business logic implemented in your code – after all, running text of your novel through a spell-checker does not guarantee a bestseller.
Final thoughts

I liked the DbFit/Fitness wiki concept – it provides simple, lightweight, intuitive framework for developing unit tests. It is also apparent that very little thought was given to logistics - integration with existing software development ecosystems, reporting and analysis.
The biggest missing piece for me is using DbFit with continuous integration server – such as Hudson/Jenkins. Since the entire framework is wiki based the automated execution presents a bit of challenge.
I can envision a Hudson job (possibly based on Maven/MsBuild packages) which checks out of SVN latest version of scripts, starts Fitnesse web server (or it might be running constantly), and then execute http requests to launch tests, then read the resulting pages (possibly convert them into JUnit format for displaying; there is also Fitnesse plugin for Jenkins). All this is doable but seems a bit flakey.
Also, this does not address traceability issues (linking test results with particular piece of code, build/release, all the way to requirements/use cases/user stories/scenarios) , trend analysis etc. Maybe in the future iterations the framework will close the gaps with enterprise level agile development, including affinity to continuous integration.

11Dec/090

Unit Testing for Project Managers

This is a brief overview of the principles behind unit testing and test driven development. The target audience: project managers. 

    Test-Driven Development: what it is and isn’t, and why it will be good for you