| By Donald King |
Article Rating: |
|
| November 12, 2005 05:15 PM EST |
Reads: |
42,699 |
What Is a Successful Build?
It is worth noting again that a successful build is not just compilation and linkage of the source code without errors; it is also the successful execution, without failure, of unit tests. Let's try an exercise with the BaseRobot class where we make a modification to the source that while successfully compiles, actually breaks the build (source code for this article is available by viewing source.html). Our BaseRobot has the ability to turn left and right and to move forward, and nothing more. Let's provide it with the ability to move backwards as well.
Following the tenets of Test Driven Development (TDD), we need to write our test first. It will go in the BaseRobotTest class and look something like this:
[Test]
public void TestMoveBackward()
{
Robot.MoveBackward();
Assert.AreEqual(Robot.XCoordinate, 0);
Assert.AreEqual(Robot.YCoordinate, -1);
Robot.TurnLeft();
Robot.MoveBackward();
Assert.AreEqual(Robot.XCoordinate, 1);
Assert.AreEqual(Robot.YCoordinate, -1);
Robot.TurnLeft();
Robot.MoveBackward();
Assert.AreEqual(Robot.XCoordinate, 1);
Assert.AreEqual(Robot.YCoordinate, 0);
Robot.TurnLeft();
Robot.MoveBackward();
Assert.AreEqual(Robot.XCoordinate, 0);
Assert.AreEqual(Robot.YCoordinate, 0);
}
When we compile the solution it fails because we have not yet implemented the MoveBackward() method. Our next step is to write code that will pass compilation:
public void MoveBackward()
{
}
The last step is to write the code that will make the test pass:
public void MoveBackward()
{
switch(_Direction)
{
case DIRECTION.North:
_YCoordinate++;
break;
case DIRECTION.East:
_XCoordinate++;
break;
case DIRECTION.South:
_YCoordinate--;
break;
default:
_XCoordinate--;
break;
}
}
My code compiles fine, but when I was implementing the logic for my robot I made an error and my coordinates are incremented and decremented incorrectly. I also became careless and decided to check back in my code without determining if my test runs properly. The continuous integration server recognized the modification to source and started a new build. Of course it failed unit testing and promptly reported a broken build (
see Figure 3).
The continuous integration server has done its job! Since I received instant feedback I not only know I was the developer who broke the build, but I also know what changed and can more easily find the issue in order to correct it. Here is the new implementation that compiles and passes the unit testing:
public void MoveBackward()
{
switch(_Direction)
{
case DIRECTION.North:
_YCoordinate--;
break;
case DIRECTION.East:
_XCoordinate--;
break;
case DIRECTION.South:
_YCoordinate++;
break;
default:
_XCoordinate++;
break;
}
}
This time I ran the tests to ensure they passed before checking in my source files. Now when I check in the source, CruiseControl.NET reports a successful build! (Note: TDD is a very in-depth subject and this article cannot possibly do it justice. A great resource on the subject is the book
Test Driven Development in Microsoft.NET by James W. Newkirk and Alexei A. Vorontsov, available from Microsoft Press.)
Summary
One last thing to mention is the CruiseControl.NET monitor that runs on the desktop as a Windows tray icon. It can be pointed to the build server and provides instant feedback to team members about the result of a build or the state of the server itself. Hopefully this article has given you the basics for getting started with your own continuous integration process quickly and easily. Once you start and maintain a continuous integration development environment, you will wonder how you used to develop without one.
Subscribe to .NET Developer's Journal Email News Alerts
Subscribe via RSS
