I’m not agile, but I have agile tendencies. I’m not test-driven, but I am a firm believer in writing tests as you develop. Treat your tests as your source code keeps you honest and on your toes. So why the post? I’m starting yet another project and I wanted to give Test Driven Development (TDD) as shot. That’’s all.

Some background. The project we have is tight. No changes there. It has a couple of releases, that we have further broken down in iterations. We are currently in the second iteration of the first release. The first iteration was to provide a live end-to-end mock up of the web site we are developing for our client. As a proponent of user-centric design, I’m keen to get the application in front of the end-user as soon as is humanly possible. As a result, and as expected, the requirements shifted quite a bit after iteration one but we, customer and us - the team - are now happy with the screen flow. Major bonus point.

Given the project is heavily database focused and it requires us to connect to legacy data, the second iteration is all about domain modelling. The technology base is comprised of all the usual suspects being Java, Spring, Log4J and WebWork as the presentation layer. My task was to take the end-to-end mock up and write the first DAO. In doing so, it would bring Hibernate to the party. So I started by writing a test.

Step 1: Create the test!

Our application has auditing requirements. Write a test to store an auditable event into the database and verify that it can be retrieved at a later date.

Status:

  • Test completed. Cannot compile code

Time Taken:

  • 3 minutes

Current feedling:

  • I’m in a dark place - this is going to take some fixing. I feel sick.

Step 2. Make the test compile

A number of classes were created such as the DAO and methods required to save and get back auditable events.
This amounted to the AuditableEventDao, the AuditableEvent POJO, an exception class to report errors and suitable documentation for these classes and interfaces.

Status:

  • Code base compiles. Test fails.

Time Taken:

  • 5 minutes

Current feeling:

  • I feel dirty. This design feels all wrong. This test driven approach has pushed me down a certain design track. I don’t like being pushed.

Step 3. Refactor

Not happy with a couple of structures so I spend some time thinking and making things a bit neater and tidied up the comments in the process. Got the tests firing up within spring.

Status:

  • Code base compiles. Test fails.

Time Taken:

  • 5 minutes

Current feeling:

  • Happier! A lot happier. I know where I’m going but still a long way from home. Time for a coffee.

Step 4. Make test succeed

This part was just plain tedious. Nasty. It was all infrastructural stuff. Getting the in-memory database running (hsqldb), writing the hbm files, configuring spring to work with hibernate, fixing the maven2 pom files, and so on. However, that said, having the test in place focussed the mind and swiftly pulled me back to the main run when i drifted off-piste experimenting with stuff.

Status:

  • Code base compiles. Test succeeds

Time Taken:

  • 15 minutes

Current feeling:

  • Pretty good. I’m out of the tunnel…but not done.

Step 5. Refactor
This was the part I enjoyed the most. The tests are succeeding and I’m tinkering with the test framework. Making things better. Removing stuff here. Adding stuff there. Running the tests to check that I haven’t dropped the ball. It’s all good stuff.

Status:

  • Code base compiles. Test succeeds. Added more tests.

Time Taken:

  • 15 minutes

Current feeling:

  • Smug. Game over. I want to write more tests…

Okay, I enjoyed myself. However, this is not the first time I’ve done this. Its just that I don’t do it all the time. More importantly, I don’t always write the test first. Will I going forward? I doubt it. But that would be the exception, rather than the rule. You can’t always develop in a TDD manner. You cannot have complete test coverage for your codebase. Any who says they have, I’d like to see it. But that doesn’t mean you cannot have a test framework that provides you with means to be make changes with confidence. For me, that’s the biggest win and the reason that we must move forward with writing more tests and if TDD helps in the battle, then I will use it where appropriate.