MSDN Magazine - February 2008 - (Page 76) Figure 1 Setting Project Include Path (Pragmatic Bookshelf, 2006) is an excellent primer. (There’s also a Java counterpart.) The meat of the book is actually language-independent, despite the language-specific title. A cute mnemonic from the book is that unit tests should be A-TRIP: Automatic, Thorough, Repeatable, Independent, and Professional. Repeatable means each test produces the same results any time it is run. Independent means tests should be able to be run in any order, with no dependencies on each other. This point will be important to remember later. Getting Started with WinUnit The first thing you’ll need to do is build WinUnit and place WinUnit.exe and WinUnit.h in known locations on your machine. Figure 2 Configuring WinUnit as a Post-Build Event You can refer to the readme.txt included with the code for more information. Next, to get started writing tests, create a test project. As I demonstrated earlier, this is just a regular C++ DLL. For information on creating a native C++ DLL project in Visual Studio, see the walkthrough at msdn2.microsoft.com/ms235636. As with other unit testing frameworks, several assert macros are provided with WinUnit for your test-writing convenience, such as the WIN_ASSERT_TRUE you saw earlier. (I’ll discuss the other WIN_ ASSERT macros you can use with WinUnit later in this section.) The asserts perform their magic using C++ exceptions, so you should keep the Visual Studio 2005 default compiler option of /EHsc when building your test DLL. However, there’s no requirement for your production code to use C++ exception handling, even if it’s linked into your test DLL. (Note that the Visual C++® 2005 toolset or later is required to use the provided assert macros.) You’ll also want to add WinUnit’s Include directory to your test project’s include path as well (see Figure 1), or to your global include paths. I designed WinUnit to work well from the command line, which means you can set up Visual Studio to run WinUnit on your test project after every build. To do so, go to the project Properties of your test project, and under Configuration Properties | Build Events, select Post-Build Event (see Figure 2). For Command Line, type the full path to where you copied WinUnit.exe followed by “$(TargetPath)” (include the double quotes). For Description, type “Running WinUnit ” (without the quotes). If you add the folder containing WinUnit.exe to your global executables path, you don’t need to specify the full path here. Alternatively (or in addition), you may wish to add WinUnit.exe to your Tools menu in order to run your tests. To accomplish this, go to Tools | External Tools and click Add. For Title, type “&WinUnit”. For Command, browse to WinUnit.exe. For Arguments, type “$(TargetPath)” (include the double quotes). For Initial Directory, type $(TargetDir). Uncheck Close on Exit and check Use Output Window (see Figure 3). At this point in the process you can select WinUnit from the Tools menu, and it will execute on whichever project is currently selected. Finally, to set up your project for debugging, go to project Properties | Configuration Properties | Debugging, and type the full path to WinUnit.exe in the 76 msdnmagazine WinUnit http://msdn2.microsoft.com/ms235636
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.