142 |
CHAPTER 6 |
Test hierarchies and organization |
machines. The automated build process is very important, and that’s what we’ll focus on.
6.1 Having automated builds run automated tests
The power of the automated build cannot and should not be ignored. If you plan to make your team more agile and equipped to handle requirement changes as they come into your shop, you need to be able to do the following:
1 Make a small change to your code.
2Run all the tests to make sure you haven’t broken any existing functionality.
3Make sure your code can still integrate well and not break any other projects you depend upon.
Running those tests lets you know whether you’ve broken any existing or new functionality. Integrating your code with the other projects will indicate whether or not you broke the compilation of the code or things that are logically dependent on your code.
Integrating your code usually means doing the following:
1Getting the latest version of everyone’s source code from the source control repository
2 Trying to compile it all locally
3 Running all tests locally
4 Fixing anything that has been broken
5 Checking in your source code
An automated build process combines all these steps under a special build script that will make sure all these things are done without human interaction. If anything breaks in the process, the build server will notify the relevant parties of a build break.
6.1.1Anatomy of an automated build
An automated build process should perform at least the bold points in the following list, but it may include many other things:
Get the latest version of all projects in question.
Having automated builds run automated tests |
143 |
Compile all the projects in their latest version.
Deploy build output to a test server.
Run tests locally or on the test server.
Create an archive of build outputs based on date and build number.
Deploy outputs to staging or even production server.
Configure and install components on target server.
Notify relevant people (by email) if any of the steps failed.
Merge databases.
Create reports on build quality, history, and test statuses.
Create tasks or work items automatically (such as adding a Team System work item) if specific tasks have failed.
The easiest way to get an automated build going is by creating a build process and scripts as soon as the project is started. It’s much easier to create an automated build for a small project and keep adding to it as the project grows than it is to start later in the game.
There are many tools that can help you create an automated build system. Some are free or open source, and some are commercial. Here are a few tools you can look at:
CruiseControl.NET (cruisecontrol.sourceforge.net)
TeamCity (JetBrains.com)
NAnt (nant.sourceforge.net)
MSBuild (http://msdn.microsoft.com/en-us/library/wea2sca5(VS.80).aspx)
FinalBuilder (www.FinalBuilder.com)
Visual Build Pro (www.kinook.com)
Visual Studio Team Foundation Server (http://msdn.microsoft.com/ en-us/teamsystem/default.aspx)
These are all configuration-based programs that allow you to create a series of steps that will be run in a hierarchy structure. You can create custom commands to be run, and you can schedule these builds to run automatically.
144 |
CHAPTER 6 |
Test hierarchies and organization |
6.1.2Triggering builds and continuous integration
The term continuous integration is literally about making the automated build and integration process run continuously. For example, you could have the build run every time someone checks in source code to the system, or every 45 minutes.
One popular continuous integration tool is CruiseControl.NET. It’s fully open source and supports both the idea of tasks, which are individual commands that are run during a build, and the concept of triggers, which can start a build automatically when certain events occur, such as source control updates.
Among the commercial tools, Visual Studio Team System 2008 supports automated builds and continuous integration out of the box. If that’s a bit beyond your budget, look at FinalBuilder and Visual Build Pro. These two commercial and highly successful build tools allow visual editing and maintenance of automated build projects. That means easier maintenance of the build file, which can get pretty scary for larger projects.
6.1.3Automated build types
You can configure many types of automated builds to produce different results or builds that run in specific amounts of time (all of which compile the code first, though). Here are a few examples:
A nightly build
•runs all the long-running tests.
•runs system tests.
A release build
•runs the nightly build.
•deploys to server and archives.
A CI (continuous integration) build
•runs all the fast-running tests.
•finishes in less than 10 minutes.
When you start writing tests, you should categorize them by their running times:
Fast-running tests
Slow-running tests