Have you ever noticed your estimation patterns between iterations/sprints?
Something that I have found on the last couple of teams, during some iteration/sprint the team‘s estimates are very optimistic and they have a significant amount of stories in the hang over state. In the next planning meeting, the estimates are very pessimistic and the team ends up finishing more than what they signed up for. And somehow it‘s very difficult to balance this oscillation.

Are we getting too reactive in our planning and estimation?

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

Agile India 2006, Asia‘s premier conferences on Agile, will be held on May 5th and 6th in Bangalore. The conference is organized by the Agile Software community of India [ASCI], a registered community of agile practitioners.

Last years ASCI organized four conferences in different parts of India focusing on creating awareness about agile methodology. This year the conference will focus on sharing people‘s experiences using agile approaches on various kinds of projects. The conference features experience reports, workshops, tutorials and various discussion forums.

The conference targets developers, testers and managers who are using agile and are interested in sharing/learning techniques and lesson learnt from the community.

Finally we have a home page for the conference.
For more details visit : http://agileindia.org/agileindia2006

We have 3 companies which are sponsoring the conference.
1. Curam Software
2. Subex System
3. Thoughtworks

We got a great response for speakers. All the speaker slots got filled in 2 weeks time. We had to reject some session proposals to keep the quality of the conference high. So we have landed up with some very interesting topics.

I‘m excited to be a part of this community and looking forward to go back to India for the conference. I had submitted 2 proposals which got accepted. I know I have to start working on them, but somehow I have this nagging feeling that it would only be done on my flight back home.

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.