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
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.
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
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: