An introduction to Test-Driven Development
02 Nov 2007Last week, I gave a short talk on Test-Driven Development, in C#, using NUnit, at the Silicon Valley Code Camp 2007. I was initially planning on posting the slides I presented, but it seemed to me that the dynamics of the process were getting lost, so I opted for a step-by-step tutorial, following essentially the code I wrote during the session.
I will follow-up shortly with another tutorial centered specifically on setting up and using NUnit, and then a few more on slightly more advanced questions. This first installement is aimed at C# developers who are not familiar with Test-Driven Development - and my objective is to provide you with the essential elements you need to get started, in an hour or so!
In a nutshell, and in the words of Kent Beck in “Test-Driven Development By Example” (Addison-Wesley), here are the steps of Test-Driven Development:
Red - Write a little test that doesn’t work, and perhaps doesn’t even compile at first.
Green - Make the test work quickly, committing whatever sins necessary in the process.
Refactor - Eliminate all of the duplication created in merely getting the test to work.
Step 0: starting point
Our mission will be to add a new functionality to an existing system, the “ShippingSystem”. The additional feature we need to put in place is the computation of the distance between cities that belong to the system. For the sake of the demonstration, we will take some liberties with reality, and conveniently assume that the world is flat, and that the distance between two points is simply:
distance(A,B) = sqrt((xA - xB)^2 + (yA - yB)^2)
To keep things simple, the “ShippingSystem” will be represented by a totally stripped-down version, namely a single class City.cs, with no members, methods or constructors, sitting all by itself in the “ShippingSystem” folder of project “IntroToTDD”. Of course, a real system would contain a gazillion of classes performing all sorts of fascinating things - but these other features are totally irrelevant to our point, and would just add confusion, so I will let your imagination fill in the gaps.
Step 1: set up NUnit
After installing NUnit on your development machine, add a reference to the NUnit.Framework to the project. In the solution explorer, right-click on “References”, select “Add Reference”, and in the .NET tab, select “NUnit.Framework”.
Add a new public class “TestsCity” to the folder ShippingSystem. This class will contain all the tests pertaining to the behavior of the class “City”. The class needs to be public in order to be visible from the NUnit GUI. Add “using NUnit.Framework” in the “using…” list, and the attribute [TestFixture] right before the line “public class TestsCity”. [TestFixture] declares that this class is a test fixture (duh!); tests that are added to that class will be visible through the NUnit GUI.
using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
namespace IntroToTDD.ShippingSystem
{
[TestFixture]
public class TestsCity
{
}
}
To verify that the setup was succesful, let’s check that NUnit can now “see” the test fixture. Rebuild your project (select Build > Batch Build > Select All > Rebuild), and open the IntroToTDD project with NUnit. Launch the NUnit GUI (from the Windows start menu), select Open Project, and navigate in the folder where your solution is stored. Go to IntroToTDD/IntroToTDD/IntroToTDD/bin/ , and select IntroToTDD.dll.
In the NUnit window, you should now see a tree view, with 4 levels of depth. Under IntroToTDD, there is a node ShippingSystem, containing another node “TestsCity”. NUnit can see that class because it is marked as a test fixture. Select the top node in the tree view, and press “Run”. All nodes should be marked with a ?, and on the right-hand side you should see in bold “Test Cases: 0 Tests Run: 0 “… This indicates that so far, there is no test to run. Let’s change that right now!
Step 2: write the first test
The first step in the process will be to write a test; fair enough, but what test should we write? Red - Write a little test that doesn’t work, and perhaps doesn’t even compile at first. The first idea which comes to mind would be to immediately test for the distance between 2 cities. Such a test would probably look something like “If City A has these coordinates, and City B has those coordinates, then the distance should be …”. We could start there, but that seems like a big first step, involving multiple functionalities which are not in place yet. So let’s take a mental note - or, much better, an actual note on a to-do list - and look for some easier step which would get us closer to the goal of having a running test.
One step in that direction would be to take a piece of the previous test, and focus on the statement “If City A has these coordinates…”. To compute the distance, we need City coordinates - how do we want to interact with these? To verify the coordinates of City A, we need to set them, and then check them. Let’s make this a test.
A test here is nothing more than a public method, written in a Test Fixture, prefaced by the attribute “Test”. Without worrying about whether it builds or works, let’s write a method “TestSetAndGetCityCoordinates”, which does just what we said:
[TestFixture]
public class TestsCity
{
[Test]
public void TestSetAndGetCityCoordinates( )
{
City sanFrancisco = new City( );
sanFrancisco.SetCoordinates( 3.0, 4.0 );
Assert.AreEqual( 3.0, sanFrancisco.XCoordinate );
Assert.AreEqual( 4.0, sanFrancisco.YCoordinate );
}
}
The test should be pretty self-explanatory: what we want to verify is that if we create a “City” sanFrancisco and set its coordinates to 3 and 4, we should be able to verify that the coordinates are now 3 and 4. “Assert.AreEqual” is the method provided by NUnit to validate that the system is in the state you expect it to be. Asserts come in multiple flavors; in this case, it will verify that the value you expect to see returned (which you have to explicity provide) is equal to the value that is actually returned by the system.
Step 3: get it to build
At that point, our code does not compile, because City knows nothing yet of SetCoordinates, XCoordinates and YCoordinates; we need to address that first. Let’s right click on the SetCoordinates() method, and select “Generate Method stub”, to automatically add it to “City”. Unfortunately, we can’t use that trick for properties, so let’s go to City and try to get to compile by changing as little as possible. Let’s add 2 read-only, internal properties returning 0.0, and let’s also remove the exception thrown in SetCoordinates().
public class City
{
internal double XCoordinate
{
get
{
return 0.0;
}
}
internal double YCoordinate
{
get
{
return 0.0;
}
}
internal void SetCoordinates( double x, double y )
{
}
}
Now let’s
rebuild - success! We can now go to NUnit, and select “Reload project”. Under
the node “TestsCity”, we have now one new item, “TestSetAndGetCityCoordinates”,
which is the test we just wrote. Run the test: all nodes show up red, and on the
right a message says "IntroToTDD.ShippingSystem.TestsCity.TestSetAndGetCityCoordinates : Expected: 3.0d, But was: 0.0d".
The red signals that the test fails
(no surprise), and the reason is that while the XCoordinate of San Francisco was
expected to be 3.0, it was actually 0.0. Given that XCoordinate returns 0.0 no
matter what, this does not come as a surprise; we know what we need to do
next.
Step 4: get it to green
Now that we have a red test, we need to get to green - Our objective is to “Make the test work quickly, committing whatever sins necessary in the process”. There is a very small modification which would get us there: replace the hardcoded 0.0 returned by the properties, by the values the test expects. No doubt, it’s a sin, but the rules say we are allowed to do it, so let’s go for it:
internal double XCoordinate
{
get
{
return 3.0;
}
}
internal double YCoordinate
{
get
{
return 4.0;
}
}
Rebuild, run the test: the nodes in the NUnit tree view are now green. We are happy.
Step 5: refactor to remove duplication
At that point, you might feel a bit uneasy; the way we made the test pass is absolutely horrendous. That’s why there is a third step: “Eliminate all of the duplication created in merely getting the test to work”. Duplication usually refers to “code duplication”: the same functionality is performed in two (or more…) different places in the application, by equivalent code. There is no obvious duplication of that type here. On the other hand, we have “data duplication”: the same piece of data is hardcoded in two different places: in the code, and in the test that verifies it.
To remove the duplication, we simply need to change the code, so that instead of a hardcoded value, it operates on a variable. Let’s add two members m_XCoordinate, and m_YCoordinate, to City, and redirect the properties XCoordinate and YCoordinate to return the variable instead of a constant.
public class City
{
private double m_XCoordinate;
private double m_YCoordinate;
internal double XCoordinate
{
get
{
return m_XCoordinate;
}
}
internal double YCoordinate
{
get
{
return m_YCoordinate;
}
}
internal void SetCoordinates( double x, double y )
{
}
}
We rebuild and run the test: we are back to red. Damn.
Step 6: get back to green
Why is the test back to red? NUnit tells us that while a 3.0 is expected in the test, the actual result is 0.0. After a quick inspection of the code, the source of the problem is clear: we have never passed the values of SetCoordinates to the member variables. Let’s fix that.
internal void SetCoordinates( double x, double y )
{
m_XCoordinate = x;
m_YCoordinate = y;
}
Rebuild, run the test: we are green.
As an aside, note how having a test in place just makes life easier: we introduced a small bug, but it immediately came to the surface. Granted, this case was pretty trivial, but it proves the point. Having tests is place is just so reassuring: you get instant feedback the exact moment you introduce a bug.
Step 7: refactor?
Is there any duplication left? No, so we can move one and add a new test.
Step 8: add a new test
Now we can get back to our initial test idea, “If City A has these coordinates, and City B has those coordinates, then the distance should be …”. Are we ready to take that one? I think so: the issues with coordinates are resolved, and the only new element here is that we need to verify a “Distance”.
The pattern we used in the previous iteration is called by Kent Beck “Fake it” (‘Til You Make It). Write a test that fails, make the test run by returning a constant, and gradually transform the constant into an expression using variables. We could use the same approach here, but for the sake of variety (and pedagogy) we will illustrate a different pattern, “Triangulate”. In the words of Beck again, “we only generalize code when we have two or more examples”. Let’s write a test with two examples of Distance computation:
[Test]
public void TestDistanceBetweenCities( )
{
City sanFrancisco = new City( );
City losAngeles = new City( );
City paloAlto = new City( );
sanFrancisco.SetCoordinates( 0.0, 0.0 );
losAngeles.SetCoordinates( 0.0, 2.0 );
paloAlto.SetCoordinates( 3.0, 4.0 );
Assert.AreEqual( 2.0, sanFrancisco.Distance( losAngeles ) );
Assert.AreEqual( 5.0, sanFrancisco.Distance( paloAlto ) );
}
To get it to build, we generate the stub for the Distance method, and clean up the return type and the argument name. Let’s run the test: we have a red test, and the message we get from NUnit is “method not implemented”: let’s implement.
Step 9: implement!
The difference between “Triangulate” and “Fake It” is immediately apparent here. Because we have two Distance computations checked in the test, there is no way we can hardcode a return value to get to green. We need to implement it for real. Let’s start, with the end in mind: we need to return a distance:
internal double Distance( City otherCity )
{
double distance = 0.0;
return distance;
}
Rebuild, and check - everything is still red. Let’s add the computation of the distance, as the square root of the sum of the square of the differences between the coordinates (or something like that):
internal double Distance( City otherCity )
{
double deltaX = otherCity.XCoordinate - this.XCoordinate;
double deltaY = otherCity.YCoordinate - this.YCoordinate;
double distance = 0.0;
distance += deltaX * deltaX;
distance += deltaY * deltaY;
return Math.Sqrt( distance );
}
We could stop there, but because we like our code to be totally self explanatory, we will rename “distance” to “squareOfDistance”, which is a better description of what the variable stores.
internal double Distance( City otherCity )
{
double deltaX = otherCity.XCoordinate - this.XCoordinate;
double deltaY = otherCity.YCoordinate - this.YCoordinate;
double squareOfDistance = 0.0;
squareOfDistance += deltaX * deltaX;
squareOfDistance += deltaY * deltaY;
return Math.Sqrt( squareOfDistance );
}
Step 10: refactor?
There is no obvious duplication left - we are done! You could still change a thing here or there, but at that point this would be mostly a matter of taste.
Conclusion
I came across Test-Driven Development through the book of Kent Beck a while back, and in all honesty I think it has been the most influential book in my practice of software engineering. What I tried to re-create here are the two things I liked most about it: its focus on simple and very actionable steps, which any software engineer can use, and the way the book itself is written; it literally showed code being written, page after page, with “live” commentary, and made it very easy to see how it was supposed to work when actually being used.
At the end of the presentation, someone asked me if I really used it. I definitely do, but I adapt the rhythm, depending on the circumstances. When writing very easy code, I would maybe skip a few steps and speed up the process; when I hit a difficult problem, I slow down and go back to very systematic red/green/refactor. It’s really a question of common sense, and of finding what works for you. There is one step I won’t skip, though - and that is writing tests as a go, hand in hand with writing code.