Organizing your build process

In this, my second post in a series on automated testing, I’m going to talk about a few steps you’ll need to take after your team has committed to automation. Diving into the deep end and immediately writing a bunch of tests isn’t the place to start. Organizing your project, preparing your code base and planning for automation are the first priorities. Of course, the assumption here is that you’re adding automation after the fact.

Organizing your build

If your project isn’t easy to build you’ve identified the first thing that needs fixing. Having a repeatable automated build is key to a successful test automation strategy. Essentially, getting your build organized means the following two things:

  • Version control
  • Continuous Integration

Version Control


The first step to organizing your build and preparing it for continuous integration is to make sure it’s under version control. There are lots of ways to implement version control but it’s the first step to repeatability which is what test automation is all about. Personally, I really like SubVersion otherwise known as SVN, and would highly recommend it particularly if you’re just starting out. There’s been plenty written about the benefits of version control so I won’t go into that here just make your choice and get your code checked in.

Build Automation

The next step is automating your build process. Jeff Atwood wrote The F5 Key Is Not a Build Process discussing the benefits of moving your build process beyond your IDE of choice and I couldn’t agree more. Build automation is really going to be the key to successful test automation. When changes are committed to your repository a build gets kicked off and subsequently launches your test automation. With this setup you’re automation is guaranteed to run against every change to your repository immediately notifying you when a change has “broken” the build.

Note: Make sure your team understands that a break in test automation that’s kicked off as part your continuous integration process is as bad as checking in a syntax error. Yeah, read that again. Even if the code builds, if the smoke test fails as a result of the check-in it should be treated as though a syntax error were checked in.

For continuous integration I’m a fan of CruiseControl.NET but as with source control you have a lot of choices. CruiseControl.NET is open source and includes a web dashboard that’s easy to modify and supports writing plugins making it easy to extend the build system. Its rather light on documentation so if you don’t want get your hands a little dirty I’d recommend something like Automated Build Studio from AutomatedQA.


Putting it all Together

If you find this to be a bit daunting, have no fear I’ve put together a 10 minute video that demonstrates this entire process from beginning to end for a simple project. Of course, your project will be more complex but you’ll get a feel for how easy it is to get going. Note, I made this video in April ’07 while still employed at Borland which is no longer the case nonetheless the video is still relevant.

Previous entries in this series:

Other related posts I’ve written:

6 thoughts on “Organizing your build process

  1. Steve,
    I like Subversion, at least on paper, but have not yet managed to get it working on my machine. I used the one-step installer that I no longer see a link to on the TortoiseSVN site. In fact, the revisions I see to that site make me hopeful that downloading the latest, and trying yet again may yield success. I’ll try that, but this is one of the problems I have often seen with open source: some things work easily, and others do not, but the (limited) docs often fail to illuminate for those of us coming new to the tool set.

  2. Steve,
    I’m writing this from my machine on Vista. I tried the one-step install of SVN, and after rebooting, XP was hosed. Something is sucking the processor dry, and I haven’t figured out yet what it is. The problem is, I have real work to do on another machine, so the recovery is not high priority right now.

  3. Wow! How interesting…. I posted that last after typing in the security code and clicking the button. Just one cycle, not two. Just the way it ought to work. Shocking!

  4. …still on Vista. The last time I tried XP on this machine, in safe mode, it gave me a BSOD.

Comments are closed.