I’m demonstrating a specific product, so you might believe that it’s a “product plug” session that’s full of marketing stuff. Thankfully, nothing could be further from the truth. I’m an avid believer in making things simple – FinalBuilder is one of many products that help me achieve that aim. Therefore, I am demonstrating a useful and highly configurable tool.
FinalBuilder has built-in support for running NUnit tests, so it’s actually remarkably easy to include running tests in your automated build process. However, since FinalBuilder is so feature-rich, I wanted to demonstrate just how easy it is to write some FinalBuilder Actions that run the tests and stop the build if the tests fail. The key take-away from this post is the ease in which FinalBuilder can be customised to incorporate new and or as yet unsupported third party tools.
NUnit has two modes of operation: via a GUI or via the command-line console. Obviously the GUI provides nice visual feedback, red and green bars, etc. The console version is less visually pleasing, but does appeal to the command-line fraternity (which suits me!) Using the command-line version of NUnit (typically found here: C:\Program Files\NUnit 2.4.3\bin\Nunit-Console.exe), you’ll be pleased to know that it will run your tests on your behalf and create as output, create a nicely formatted XML document. That XML document contains two rather useful attributes: total and failures – these indicate the number of tests that were run and the number of failures.
Clearly we can make use of the failures attribute to our advantage. If it’s zero, then the automated build process can continue on. However, if it has a value of one or more, clearly we have a problem, the build is broken.
Without using FinalBuilder’s built-in NUnit Action, how might we go about incorporating NUnit into our FinalBuilder build process? Thanks to the power of FinalBuilder, it’s actually remarkably easy. Assuming that you have a new, clean FinalBuilder project, here’s what you do:
1. Goto the Tools -> Edit Variables menu, add a new variable called TestFailures.
2. Add a new Execute Program action (from the Windows OS action group). Set the Program File input box to point to nunit-console.exe. In the Parameters input box, enter the name of the DLL that contains your NUnit tests. In the Start In input box, enter the full path to the directory where the DLL that contains your tests can be found.
3. Add a new Define XML Document action (from the XML action group). Call the XML document TestResults. Set the Load document from file input box – set it to the TestResults.xml file that sits alongside the DLL that contains your tests. This assumes that you have either places an empty TestResults.xml file in that folder or you have run your tests through the NUnit Console prior to this exercise.
4. Add a new Read XML Value to Variable action. Set the XPath to Node equal to //test-results. Put a tick in the Read attribute check-box, set it equal to failures. From the Variable to Set drop-down menu, set it to TestFailures.
5. Add an If..Then action (from the Flow Control action group). Set the Left-hand Term equal to %TestFailures% – there is code completion to help you. Set the operator equal to “greater than”, i.e. >
6. Run your FinalBuilder project. If all goes well, i.e. the tests pass, the screenshots below should look familiar. Otherwise, if the tests fail, the whole build process fails.
This short example demonstrates the power of FinalBuilder – whilst there is a built-in action for running NUnit projects, this example has served to demonstrate how easy it is to integrate a third party tool into the FinalBuilder build process. Hopefully this short example has been enough to convince you that FinalBuilder can be used to integrate virtually any “build activity” that you may have in your process.
How are you carrying out your build process at the moment? Is it automated? Harness the power of the fully automated build!