MbUnit In An Agile Environment

“An agile environment” may mean different things to different people reading this, so first a definition. Being able to write tests as you write your code ensures that whatever new code you create, it still does what you think it should. Towards this goal then, an agile environment here means that

• your code resides on a source control server so that changes are easily accessible to all and prior versions are available if tests fail after code is committed to the server
• scripts exist on your server which automate the building, testing and deployment (to a staging server) of your production code, typically using NAnt or MSBuild
• these scripts may or may not be triggered automatically according to a given set of rules. For example, by each new code committal to the source control server, or at the close of business each day. This is known as automated continuous integration.

There’s much more to the practice of agile software development than this, but from its role as a unit testing framework, MbUnit has a say on these three things (besides how you actually write tests) and to that extent includes

• Custom automation tasks for NAnt
• Custom automation tasks for MSBuild
• Plugins for CruiseControl.Net, one of the most common pieces of continuous integration server software for the .NET platform
• Test run reports generated in any of four different formats for your scripts to consume as required.

We also offer our thoughts on how you add MbUnit to your source control server.

For a great overview of setting up a simple automated build environment (which could then be integrated into Cruise Control.NET) have a look at Mike Roberts’ excellent series of articles on how to build a .NET development tree. You can find them all at the TreeSurgeon CodePlex site located towards the bottom of the home page. TreeSurgeon is Mike’s stab at automating the creation of the tree he describes, now maintained by Bill Simser