Integration with NAntRunning tests in a graphic display is nice, but it is time-consuming for large projects. Adding tests to a test fixture is as quick as adding the functionality it is supposed to check. But now it would be nice if the tests were automated, right? Right. This is where the integration of NUnit and NAnt comes into play. Integrating a little knowledge about the tests into the build is a marvelous thing because it does not make much sense to allow a build to leave Engineering that does not even pass the unit tests! NUnit TaskLooking back at the NAnt Build File Template in Listing 4.11, the output property was the fully qualified path name to the built assembly. Listing 6.4 shows a simple NUnit task making use of the output property. Listing 6.4. NUnit NAnt Task<target name="test" depends="build"> <nunit2> <test assemblyname="${output}"/> </nunit2> </target>Listing 6.4 shows the dependency on the build target so that the latest code is always tested. It would make sense to have the test target run automatically in the master build file. However, you should design the build in such a way that the developers can directly call just the build target for faster compilation at design time. The code in Listing 6.4 is the simplest use of the NUnit2 task. There are other attributes that allow further customization of the task. NUnit2 AttributesThere are two main attributes for the NUnit2 task beyond the common attributes that all NAnt tasks have. Those NUnit2-specific attributes are formatter and test. Formatter allows customization of the default formatter output for the task. The test attribute allows you to specify a specific test or tests to run. If no tests are specified, all tests are executed. Test AttributesThe test child node of the NUnit2 task in Listing 6.4 also has additional properties that are not exhibited in the example. Having a test be a child node of NUnit2 allows tests to be run from multiple assemblies. Three additional attributes for test are appconfig, transformfile, and testname. The functionality of these attributes is almost self-describing. Appconfig allows you to specify the name and location of the .NET XML config file to use in testing. The transformfile allows you to specify an XSL transform to run on the formatter output when using XML. Testname allows you to specify a specific test to run. Again, if no tests are specified, all tests are run. NUnit Report TaskThe problem with automating the tests is that you lose the nice graphic display of passed and failed tests. In the design of the build, you want to fail the build if a test fails, but you do not want to abort the build on a single failure. If code early in the build fails its unit tests, continue the build to allow other code to be tested. This is possible by using a global property, possibly as an environment variable. Then at the end of a large build, how do you tell which test passed and which failed? By using the NUnit2Report task (http://NUnit2report.sourceforge.net/indexl), you can capture the results of the tests in the easy-to-read graphical format shown in Figure 6-3. Figure 6-3. NUnit2Report for NUnit Tests from the NUnit2Report Web Site.Figure 6-2, but run in an automated fashion and with a little nicer output format. The NUnit2report task is a NAnt task that is simple to use and install. Listing 6.5 shows the simplicity of the task. Listing 6.5. NUnit2report NAnt Task<nunit2report format="frames" opendesc="yes" todir="HTMLResults"> <fileset> <includes name="result.xml" /> </fileset> <summaries> <includes name="result.summary.xml" /> </summaries> </nunit2report>Table 6.4 gives a full listing of the available attributes for the NUnit2report task.
By designing the tests first and with proper use of this task, you can almost track the status of your code. This, in conjunction with Continuous Integration discussed in the next chapter, can help you schedule more accurately. |