On Friday I held a class on test driven development for the group of developers that will be expected to start developing using TDD soon. For many it will be their first experience with TDD.

I demonstrated how to do TDD in a live coding session where I rapidly added features to a web service application by cycling through the red-green-refactor process several times.

I think the concepts and practices were well understood by everyone and I’m hopeful that we’ll be successful in migrating from a non test-driven culture to a test-driven culture.

The questions after the coding session were mostly focused on how to test the existing code; the code that has low cohesion and high coupling; the stuff that’s hard to test.

How to start testing large, untested applications

I suggest the following approach:

1. rank application features by total cost of ownership by looking at how much time and money is spent fixing defects and handling customer support issues
2. look at upcoming feature requests and consider where the system needs to be changed

Start by testing the areas that cost the most to support and the areas that need to be changed significantly or frequently.

Choose black box tests that cover the visible features rather than the implementation details behind those features.

Use tools like WATIR or WATIN to assist with manual testing by using them to execute test setup while still using manual verification.

There is no silver bullet. Untested codebases are expensive to test. In general I think the best you can do is to control costs, focus on tests with the highest potential ROI, and ensure that new features are tested.

Have you ever tried to introduce test driven development to a project or company you worked for? Perhaps they were already familiar with the concepts and wanted to do test driven development but it just didn’t work for some reason. It’s hard to get everyone doing it and it’s even harder to show the value in a short enough time-period to keep developers and stakeholders motivated to stick with it.

I was shown how to test-drive development by Ted O’Grady, Joseph King, and Gerard Meszaros while we were at CGI writing an oil and gas production accounting system. It was a very large complex system that was test driven from day one. The tests saved us a lot of time and provided much more benefit than they cost. I can’t count the number of times I was saved by the tests, and I can’t thank Ted, Joseph, and Gerard enough for their valuable lessons.

Writing effective NUnit test methods

In this post I’m going to share with you what I know about writing effective test methods. Good test methods are clear. That is, they are easy to understand at a glance. They test one thing and only one thing. They delegate when setup or asserts are complex without obscuring the test’s intent. Good test methods are clear and easy to maintain.

How to write a test method

1. Decide where the test should live. Is there a suitable test class already, or should you create a new one?
2. Add the test method to the appropriate class. Give it a meaningful name and add the three sections: setup, execute, assert using comments.
3. Start by writing the asserts and work backwards. This will keep you focused on the goal of the test. The code may not compile yet, but that’s okay.
4. Write the execute step as described by the test method name.
5. Fill in the setup section as required to initialize the test fixture.

I will cover how to come up with good test cases in a future post.

Decide where the test should live

I usually group tests by domain concept rather than by system layer. For example say I needed to write a test relating to a new language being implemented for a spell checker. I would favor putting the new test in a class named FrenchTests rather than DAOTests or DatabaseTest.

Add the test method

This is how I was always set up my NUnit test methods. With Java I use IntelliJ live templates to save keystrokes. With C# I use Refactor! or ReSharper templates.

The name of the method is important. TestGetValue_NoValueSet indicates that this test will be testing GetValue under the condition NoValueSet. Always indicate what you’re testing and what (if any) the special conditions are.

Start by writing the asserts

The assert step is where the test method verifies that the result of the execute step is what we expect. NUnit provides many built-in asserts to help with this, and it is also possible for you to write your own custom asserts.

Write the execute step

The execute step is what exercises the system being testing. The test name should clearly indicate what this method is. The test method is TestGetValue_NoValueSet, which indicates that the method being tested is “GetValue”. Therefore, the execute step should be a clearly visible call to the GetValue method.

Fill-in the setup section

This is what the test looks like now:

Now you have added a decent test method, which is the first step in TDD. Next you will need to make the code compile and eventually implement GetValue on testObject such that all tests pass. Adding new test methods is the first step of a larger TDD process commonly referred to as RED-GREEN-REFACTOR. Which roughly means: write a test that fails - make it pass - clean up the test and the production code.

I am in the process of introducing TDD to the company I recently joined. Many of the developers I work with now are convinced of the potential value of test driven development. I hope that by sharing some of my practical experience we can succeed in establishing this practice and reaping it’s benefits.

If you have tips or experiences that you would like to share, please add a comment.

Automation of tasks such as building a system is more than just a time saver. The knowledge required to build a system should not reside solely in the heads of the original developers.

An automated build script contains the knowledge of how to build the system. This is very important information that needs to be shared and kept up to date to make it easy for new developers to build the system. This reduces the risk that the knowledge will be lost and decouples the original developers from the system being built, allowing them to move on and start new projects.