I just released a new version of FIT Decorator. The latest version supports a build-in Fitnesse wiki for you to see the examples.
In addition to this, all the time based fit decorators have been updated to display the actual time taken.

Fit Decorator has also been ported to Python by Jens Engel. We have not yet released this, but you can have an early glimpse from the source repository.

For more details: http://sourceforge.net/projects/fitdecorator

Over the last couple of days I was wondering how to hot deploy webapps in Tomcat? After trying all possible search queries in Google I gave up. But I knew for sure that it was possible to hot deploy webapps in Tomcat, as I had done it before.

I started playing with Sysdeo Eclipse Tomcat Launcher plugin. This plugin had an option to make the context reloadable. It actually updates the server.xml under the tomcat/conf dir. This is how I figured out how to make this work for any webapp.

Just add the following line to the server.xml

<Context path=”/yourContext” reloadable=”true” docBase=”rootFolderOfYourApp” />


Now I don‘t have to stop and start tomcat for a small change in a class file to reflect.

Recently I released the beta 0.2 version on Patang. In this release I added support to run plain Fit tests inside the container [web container]. So now, you can run your fit tests inside the container. It does not matter if you are using plain Fit or FitNesse.

Setup for Fit:
1. Add the fit.FitServlet definition to the deployment descriptor of your web container [web.xml]. An example is available under the docs/web.xml in the release file.

2. Add the absolute path to the directory containing fit tests and the results directory as init-params to the servlet.

3. Deploy the patang-fit.jar file to you web app by putting patang-fit.jar and fit.jar under the WEB-INF/lib folder.

4. If you plan to call your fit tests during your continuous integration build, use the fit.ServletInvoker class, which communicates with the fit.FitServlet in the web container. This servlet can be used to run your fit tests inside the container directly from the web browser or from the ant build file. An example of this is available under the docs/build.xml in the release file.

More details:
http://sourceforge.net/projects/patang

My current project is a J2EE project which uses JDOs for persistence. Off late there has been a huge emphasis on running our unit and unit integration tests inside the app container. With lack of IoC and DI, the code does behave different inside the container and outside the container. Given this as the reality of the world which we cannot change, how do we test drive our code?

So we started of by using JUnitEE for running unit tests inside the container and FitNesse for acceptance tests at the service level. FitNesse does not run inside the container. Hence remote debugging, EJB refs and other container provided facilities could not be used. So I started a new open source project called Patang which gives you the infrastructure to run Fit/FitNesse inside the container through a FitServlet.

Now we had JUnitEE tests testing individual layers of our services, while FitNesse test doing more of what we call end to end service test. We found the following problems with this approach:
1. There seemed like a lot of duplication of test coverage and test data in these 2 types of tests.
2. JUnitEE is as bad as FitNesse tests in terms of quick feedback. In both the cases we need to redeploy our code to the container to test it.
3. Any refactoring meant changes in 2 places. So maintaining the tests became a costly affair.

Because of these problems, we started just writing fit tests and driving our development using FitNesse tests. It seems to be working fine so far.

I feel this approach gives us the following advantages:
1. Fit is pretty good to express the intent. It helps to clearly express what needs to be done. What are the inputs and what are the outputs.
2. It is very good in separating setup data from the actual test itself. So it‘s much easier to understand.
3. We are using just one tool for in container testing and hence decrease learning curve for new team members.
4. Much less test maintenances. It‘s all in one place.
5. Our tests cater to a broader audience. It‘s no more just a developer tool. Our testers can take these fit tests and enhance them with different scenarios. This helps them to keep pace with development. And sometimes drive development to some extent.
6. xJunit is not very good at setting the context and providing explanation to the tests. With Fit we can make our tests more like stories and hence bring them closer to our acceptance tests.

Side effects of this approach:
1. It is much harder to refactor your code, because now you have the fit test and its associated fit fixture. When we rename a method/class or change a method signature, the fit fixture gets refactored by the IDE. But the fit test can be difficult to refactor. It can be even more difficult to maintain them if the test pages are not inside the project structure.
2. The feedback cycle is longer. But same as any in container testing framework.
3. Writing and maintaining the fit pages is a very difficult task. It can get very cryptic. There is no decent IDE to do this. [May be my next open source project]

Some myths associated with this approach:
1. We are moving tests away from the code. I don‘t think so. The fixtures are still organized in the same way we organize our tests.
2. More maintenance. Much better than applying changes in 3 different places. [JUnitEE and then acceptance tests]
3. No IDE support. One can easily use the FitRunner class to run fit tests from the IDE.
4. Cannot be made a part of the build process. Patang project provides you with a ServletInvoker class which can run all your fit tests inside the container and publish the results.

This seems to be working fine for us so far. In the end that‘s what it boils down to.

Patang is a framework for testing server-side code. Patang intends to simplify writing and executing acceptance and unit integration tests for server-side code. It implements an in-container testing strategy, meaning that the tests are executed inside the container.

Patang provides the infrastructure/framework to run fit tests inside the container. What type of fit tests you write will determine which type of testing you can do with Patang.

Currently Patang works only with fitnesse. But the vision is to make it generic.

Why another framework?
Several kinds of functional and unit testing frameworks are available for testing enterprise applications. They can be broadly categorized into 3 types:

1. Unit isolation testing. State based or interaction based testing frameworks such as JUnit or Mock objects seem to fit well.

2. Unit integration testing. These tests will exercise the interactions with the container. Frameworks like Cactus, JUnitEE, etc suite this category.

3. Functional unit integration testing. Frameworks which let you test full use cases which can be composed of several requests/responses cycles. Some times these are also referred to as unit acceptance tests. HttpUnit, Fit, etc fit into this category.

Mostly on enterprise projects, three or more, different frameworks are used just to test the functionality of the code. Patang proposes to use Ward Cunningham‘s FIT framework to achieve second and third category of testing. This can be easily achieved by running FIT inside the container by having a FitServlet, which can execute the fit tests.

Advantages of this approach:

1. Reuse of tests. Usually there is an overlap between acceptance tests and integration tests. We can use pretty much same/similar fit tests for both.

2. EJB References, JNDI lookups, transaction management, container security, data sources and other container provided facilities can be used the same way in test environment as in development environment.

3. Test First Development: Helps in driving development with a failing tests. These are mostly black box tests at different layers of the architecture.

4. Easy of deployment and maintenance of test and development environments. All you need is the servlet and the fit framework running.

5. Remote debugging: It is very easy to debug your server side code by driving it through tests and stepping through the code in your favorite IDE

6. Bringing test environment much closer to production environment: In most of the enterprise web applications you have a web front end running inside a web container calling business components running in an application server. Executing FIT tests using patang, simulates the web front end and hence is much closer to the real world.

How patang works?
Patang provides a servlet which executes the fit tests inside the web container using the FitServer class. This helps us setup remote debugging on the web container and easily debug the fixture, business delegate and actual EJB code. This also helps us to avail all the EJB ref look ups and other container provided services. With the fit tests running inside the container, we can use the container?s class load and hence we do not need to maintain classpaths on .root page.

Some day Patang can become a good alternative to Cactus and JUnitEE.

For more details: http://sourceforge.net/projects/patang

I have added some more interesting decorators to the fitdecorator project.

The latest version of fitdecorator supports both Fit and Fitnesse.

Any feedback/suggestions are welcomed!

This is an over simplified summary of my experiences, handling database changes on different agile projects.

Most of the projects I worked on, we were using ANT for our builds. So we automated our database scripts using ANT.

List of things that need to be in place for this to work:

1. Ever developer has a database instance, either on local machine or on a central server. Local machine is preferred. Properties file can be used to point to the correct database.

2. The development team is following an iterative development model. At the beginning of each iteration/sprint, someone on the team [DBA or build master or someone] creates a baseline of the database from the current database snapshot and stores it in a central place. This baseline can then be used by every developer to bring their DB instance to the baseline version.

3. Under the project directory, we create a folder called DB. This folder contains one folder per iteration/sprint. All the database scripts are added to the respective iteration/sprint folders in which they are created. The whole DB folder is checked into version control along with the code.

4. In the build.properties file, declare a property called current.iteration.number. This property is defines the current iteration or sprint number and is used by the targets in ant to get the baseline DB.

I would like to describe the different scenario that can occur on a project irrespective of whether you have a dedicated DBA or not.

Scenario 1: Developer needs a database change
Developer Activities:
1. Create a sql script [with or without DBA‘s help] as per standards in the appropriate DB folder
2. Apply script to local database using appropriate database client [Eg. Query Analyzer for MS SQL Server, Toad for Oracle, etc]
3. Test application against local database
4. Check in the script into version control

Scenario 2: Team member needs to get database changes made by others during the current iteration/sprint
Developer Activities
1. Update the source tree from version control system. This should get all the database, code and configuration changes from the version control.
2. Run the default ant target [build verification] at the project level (this will run the ‘updatedb‘ target that executes all new database scripts on the local database)

Scenario 3: Beginning of Iteration/Sprint
Activities
1. Backup the database from the build/QA server at the same time as labeling the codebase in your version control (If the team has a Build Master then it‘s that person responsibility to label the codebase and take the backup). The baseline can be checked into version control. Its optional.
2. Update the current.iteration.number in build.properties to the latest iteration/sprint number
3. Run ‘restoredb‘ ant target to get the baseline version of the database for the new sprint.

Scenario 4: Local Database is messed up
Developer Activities:
1. Update the project tree from source control to make sure you have all the latest changes.
2. Run ‘forceupdatedb‘ ant target to restore the baseline database for the current iteration/sprint and to catch up with the latest changes. [Executes the ‘restoredb‘ and ‘updatedb‘ targets]

Properties of SQL Scripts:

1. Naming convention: yyyy-mm-dd-hhmi.sql
The scripts are named based on the time of creation. The name is used to execute the scripts in the order of creation.

2. The scripts should be incremental .i.e. you should never modify an existing script.
For example, you create a new table and check in the create table script. Then you need to add a new column to this table, you should create a new alter table script. The same goes for objects that you cannot modify like stored procedures. You would create new scripts that drop the existing procedure and create the procedure again with modified code.

3. The scripts need not be re-entrant .i.e. if the same script is execute multiple times then they can fail. We use the modified selector on the FileSet element. The modified selector selects files if the return value of the configured algorithm is different from that stored in a cache. So if a file is not updated, then it does not execute the file. This means, only new scripts are executed and the old ones are executed only once.

http://ant.apache.org/manual/CoreTypes/selectors.html#modified

If you want to be sure that the scripts are executed only once, then you could create a version table in database and have the sql scripts check the version to decide if it needs to be executed. The script would insert a row into the version table if it has to be executed. This also gives us the ability to restore databases to a specific version.

All these tasks can be achieved by three simple ant targets:

1. updatedb: Executes all the new (or modified) sql scripts for current iteration/sprint against local server. It executes the scripts in the order of their creation time, based on the script‘s file name.

2. restoredb: Restores the database from the baseline version.

3. forceupdatedb: Executes all sql scripts for current sprint against local server after restoring the local database from the baseline.

To see the actual build file and sample DB folder with sample scripts click here

Note: the scripts and ant targets assume that the database is SQL Server. They can be easily modified for other Databases.
Download the DBChangeManagement.jar and rename it to DBChangeManagement.zip.

In ANT, the optional ‘description‘ attribute can be used to provide a one line description of any given target, which is printed by the -projecthelp commandline option. Targets without such a description are deemed internal or private and will not be listed, unless either the verbose or debug option is used.

But what if you want to create a target which cannot be executed directly? A target which is meant only for internal use by other targets and cannot or should not be executed as a standalone target.

A small and elegant trick I learnt from a colleague at ThoughtWorks is, let the target names begin with a dash, e.g., -init
[target name=“-init”].

If you try to execute this target from the command promt, it would be considered as an argument and ant will give the following error: Unknown argument: -init

Simple and handy trick when working with large build files.

1. Fixture.getArgsForTable(Parse table)
a. Fit: Method is at protected access level
b. Fitnesse: Method is at default access level

2. Fixture.loadFixture(String fixtureName)
a. Fit: throws InstantiationException, IllegalAccessException
b. Fitnesse: throws Throwable

3. Results page:
a. Fit: Directly adds colors to the resulting columns [Ex: for Right = #cfffcf]
b. Fitnesse: Adds different style values to the resulting columns [Ex: for Right = ‘class=“pass”‘

4. Counts: The number of exceptions and ignored can change based on the type of exception.

There are lots of other small differences which can make moving between fit and fitnesse tricky.

ASCI is planning to organize its annual conference in Bangalore on 5th and 6th May 2006. The theme for last year‘s conference was “Introduction to Agile”. We are hoping people have spent the last year or more using and adopting to agile and would have some good insights into the methodology. This year‘s conference plans to help people share these insights and focus on more advance topics in Agile.

Currently we are looking for speakers. So if you have some this topic, please contact me.
For more details: http://agileindia.org
Mailing list: http://groups.yahoo.com/group/agileindia