I'm digging lately with my team into our new product. We are using a full stack of buzz words in our development like .NET 2.0, Atlas, WCF , etc... We are using SCRUM (at least that was the primary goal) to manage our dev process and some useful XP techniques to make our life easier.
The system that we are building is actually a general ASP.NET based application framework, which got it's own development tools.These dev.tools allow customization of the system on the customer's site. The dev. tools are intended for using by non-technical(at least none-geeks) people(consultants, distributors, customers).
In general the user functionality is organized in so called TASKS. Every tasks is a mini workflow consisted from a number of states(called STEPS) and transitions(called ROUTES). Every step may have a corresponding view (this is what the user sees) and every step and route may have attached a set of Code Units. A Code Unit is a sequence of actions coded via custom XML based language. The Code Units" actually are the logic that drives the application behind the scene.
Our first application to develop with this framework is a mass market HR solution and we intend to deploy it on few thousand sites during it's life cycle. We realized, that this highly customizable solution is about to cause us a serious maintainability related problems if managed in a traditional way. Our HR solution will be deployed and configured with a standard set of TASKS,CODEUNITS, VIEWS ,and other customizable objects. The standard set of customizable objects in the system may outnumber few thousand. After the solution deployment our customers receive updates of the product usually every 2 months(or even more frequent). One reason for this is the frequent changes in the legal regulations regarding the payroll law in our country. There are other reasons as well , however the main point here is that we'll have to update frequently a large number of product sites, which eventually will be customized in their own way. Every site will have a standard set of objects, but may also may have modified and fresh new objects as well. This forced us to design a simple and efficient business process to handle this issues, which I will not discuss here. Part of the solution for us is the use of Fitness and Selenium.
We are already TDD driven and using NUnit to do our unit testing. However we needed a tool to minimize the gap between our business analytics and our devs. While seeking for a solution I've found this article by Jeremy Miller. We've decided to use a similar approach.
After installing Fitnesse and Selenium on our build server, we've created a simple(and effective) "testing" language for our product. We wanted to have a live product spec. We wanted to have our standard set of TASKS defined by our business analytics described in a useful and simple language in our live spec document.
Following a simple example of a TASK defined:
This table contains a testable description of the normal flow of a task with identifier dps0001. The task is intended to allow entering of a new employee master record and it is consisted of 2 steps. The first step alows entering of the employee's social number and some dates. The second step allows entering some address information. There is one transition(Route navigation) between the two steps and one transition after step 2 to finish the task.
You may think of it like a story card for example. The good thing here is that you may have a bunch of natural language text here around the testable description
| Start Task | dps0001 |
| note | STEP 1: EMPLOYEE GENERAL INFO |
| Set TextBox | SocialNo0 | | 6603066766 |
| Set DateTimeBox | BirthDate0 | | 1.1.2005 |
| Set DateTimeBox | IdCardIssueDate0 |
| 1.1.2005 |
| check | Navigate Route | next | | false | |
| note | STEP 2: EMPLOYEE ADDRESS |
| Set TextBox | Country | | Bulgaria |
| Set TexBox | City | | Sofia |
| Set TextBox | Line 1 | | Stara Planina Str. 41 |
| check | Navigate Route | save | | true | |
| Stop |
After starting the test, the table utilizes our special Fixture class (it inherits FitLibrary.DoFixture) called OmeksEntFixture. The OmeksEntFixture class mixes the Fit and Selenium functionality. It will perform few HTTP requests towards our testing server and hopefully the table will turn in GREEN to indicate that the story is already implemented .. OR... the devs will soon realize that there is another story that turns in RED and needs attention. The good thing here is that the implementation is already hard-linked with the spec (forever :) ) and our build process will never succeed until the story is not implemented as specified.
As we are using
CC.NET as a build integration platform, we placed the Fitnesse/Selenium tests into our build process. It took us about 2 weeks to reach the moment to integrate our live and testable spec document with the set of the agile dev. techniques that we are using.
<COMERCIAL BLA BLA>
Now as we have this great tool for filling the gap between our business analytics, we will use this silver bullet to shoot all the problems and to deliver the project on time and within the half of the budget! :)
</COMERCIAL BLA BLA>
Links :
FitNesse WebsiteSelenium RC web siteFitnesse and .NET - a basic tutorialCreate a Testing DSL with Fitnesse and SeleniumAutomated Web Testing with Selenium Driven by .NetHow to integrate FitNesse acceptance tests into your CC.Net buildHow to get FitNesse to switch to .Net modeSome good posts on Fit, by James Shore
