WinUnit: Simplified native C + + application unit Testing

This article discusses:

Unit Test principle

Set WinUnit

Building test Equipment

Implementation and Customization

This article uses the following techniques:

C + + and visual Studio

Directory

Start testing Now

Getting Started with WinUnit

Appliance: Setting and Clearing

Run WinUnit

Implementation Details

Deep study ...

At the moment, it can be very difficult for native code developers to feel no pressure-like developers using the Microsoft®.net framework have all the best tools!

I have always been interested in the rich experience of engineering practice, but the so-called "engineering experts" have repeatedly let me down, they will only praise the advantages of unit testing, and in the test tools for their native code to make suggestions when they say nothing. I think the tools that are easiest to integrate into an automated build system are the NUnit equivalent framework for native code, which is what I really need. In other words, I want to be able to build a DLL that contains only tests, an external test run program that can run these tests, and the ability to report and log records. I also want to be able to declare only one Test at a time, with as few extra code as possible in my test DLL.

As a result, I built a native code unit test tool called WinUnit. I'll give you a more detailed introduction later, so here's a quick look at how easy it is to create and run test DLLs using WinUnit. First, create a CPP file, which we hereby call DummyTest.cpp:

#include "WinUnit.h"
BEGIN_TEST(DummyTest)
{
　 WIN_ASSERT_TRUE(3 > 4, _T("You should see this error message."));
}
END_TEST

Use the following command to build it into a DLL:

cl /EHsc /LD DummyTest.cpp

Then perform winunit on it:

>WinUnit DummyTest.dll
Processing [DummyTest.dll]...
(DummyTest)
DummyTest.cpp(5): error : WIN_ASSERT_TRUE failed: "3 > 4". You should see this error message.
FAILED: DummyTest.
[DummyTest.dll] FAILED.　Tests run: 1; Failures: 1.
There were errors.
Tests run: 1; Failed: 1.

Of course, changing 3 > 4 to True Expression 4 > 3 will not fail.

WinUnit will accept any number of DLLs or directories, process them, report the overall results, and return the exit code. By the way, as the name suggests, WinUnit will only run on Windows®.

I admit that before I wrote my own tools, there were other options in the world for C + + unit testing. However, I found that there is a problem with the existing unit test tools, which are usually more prioritized for portability than they are easy to understand and can be used directly. Cppunitlite is one of my favorite portable devices, but because its design is highly customizable, it costs more than expected to set it up. Since the test run program and the test are both completed in the same binary, the line between the two is blurred, and you need to write code that actually invokes the test run function and place it somewhere. In addition, because it is difficult to explain complex macro implementations to colleagues, the implementation of macros is difficult to adopt. However, if you need to be able to migrate to other operating systems, Cppunitlite is definitely worth a look.

For a long time, other options available for C + + unit testing are the same as those available for testing. NET code, most notably the NUnit and visual Studio®team Test Unit Testing framework. Because both of these frameworks can execute any. NET assembly with the appropriate attributes, you can use these tools for testing that is written in Managed C + + (now C++/CLI). I find the main inconvenience of this approach is that these tools are designed specifically for. NET development, not for native code. This may not be surprising. However, it is difficult to use most of the Assert methods provided for native C + + (because these methods require a. NET-style object), and as a developer, you need to be very familiar with c++/cli (or Managed Extensions for C + +) to write tests. You can find more detailed information about the limitations of this practice from the footnotes in the Visual Studio 2005 Product feature comparison page (msdn2.microsoft.com/vstudio/aa700921.aspx). As I mentioned earlier, I find it important to "easily convince my colleagues to use it", and the use of managed tools can set additional hurdles in this regard.