Entries from November 2007 ↓

I just read a great post on Logic+Emotion called Waking Up Sleeping Giants. I think the younger entrepreneurs who are involved in creating new companies will get first-mover advantage in this changing environment and many established companies risk falling behind very quickly if they don’t embrace change.

I love the quote from Fuzzy Tail -

We can no longer afford to over-analyze our challenges. We must try to get things launched—learn from these experiences and refine. We must define ourselves and what we do more broadly while retaining the potency of our our crafts. It’s about going from left brain to right brain and ending up on “light brain”. We must become “fuzzy”.

JumpBox provides pre-packaged OS and software bundles that are ready to run inside a virtualization system. For example, one JumpBox is preconfigured to run WordPress on Linux.

I stumbled onto JumpBox this morning and was surprised when I read that there are currently no (affordable) hosting solutions for JumpBoxes.This leaves a huge opportunity for someone to create a hosting solution that would allow people to quickly and cost-effectively spin-up JumpBoxes. I can’t believe JumpBox missed this.

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.