Author: cpluser Website: http: //tdd.nease.netemail: cpluser@hotmail.comblog: http://blog.9cbs.net/cpluser/ Demo Code Download
Third, the CPPUNIT development environment has known CPPUnit's test environment. If you are already in a rusty, you are ready to feel the test drive development during your development process. However, before using CPPUnit, you need to set your development environment. 1. CPPUnit LIB and DLLCPPUnit provide we with two sets of framework libraries, a static lib, a dynamic DLL. CPPUnit Project: Static LibcppUnit_dll Project: Dynamics DLL and LIB we can make choices based on actual conditions. Enter the SRC folder to open CPPUnitLibraries.dsw. Compile these two Project, the output position is a lib folder. Another Project that needs attention is Testrunner, which outputs a DLL that provides a GUI-based test environment, which is one of the two test environments we mentioned earlier. We also need to compile this Project, and the output location is also a lib folder. To facilitate development, we use these compiled libs and dlls (including Debug and Release Edition) Copy to our own folder (of course, you can don't do this), such as f: /cppUnit1.9.0/lib / And we also also put the CPPUnit source code COPY to our own include folder. Then set the include path and lib path in the Tools / Options / Directories / Include Files / Directories / Include Files and Library Files. Don't forget the correct LIB in your Project. 2, open the RTTI switch in your VC Project. Specific location Project settings / C / C language. 3. Set the environment variable Testrunner.dll for Testrunner.dll.dll provides us with a GUI-based test environment. In order to make our test program call it correctly, Testrunner.dll must be in the path of your test program. But the easiest way is to add Testrunner.dll's path to the path to Testrunner.dll in the environment variable path of the operating system. Fourth, your first TDD EXAMPLE is ready, now we can take a look at how to add a test code. As we mentioned, the minimum test unit of CPPUnit is Testcase, and multiple related TestCase form a testsuite. The simplest way to add test code is to use CPPUnit to make several macro we provide (of course, there are other manual joining methods, but all the same way, everyone can check the demo code in the CPPUnit header file). These macros are: CPPUNIT_TEST_SUITE () to start creating a TestSuiteCPPUNIT_TEST () Add TestCaseCPPUNIT_TEST_SUITE_END () End Create TestSuiteCPPUNIT_TEST_SUITE_NAMED_REGISTRATION () to add a TestSuite to a designated factory TestFactoryRegistry interested friends can look at these macros in a statement HelperMacros.h This article does not detail here. 1, a class that implements two integers added vacation, we must implement a class, class name is temporarily tied, and its function is mainly to achieve two numbers (more simple classes, this also test? Don't tighten, we just know how to join the test code to test it, so the more simple and better. Assume that the addition method to be implemented is: int Add (int NNum1, int nnum2); OK, let's write the code of this method first.
TDD is written first, after writing product code (CPLUS)! The test code written first is often unable to run or compile. Our goal is to write product code after writing test code, making it compiled, and then reconstructing. This is the "Red / Green / Refactor" that Kent Beck (Remember the Status section of the GUI-based test environment?). Therefore, the above class name and method should be just in your heart, but it is just your IDEA. 2. Create a Project for test code in the VC usually, test code and test objects are in different Project. This will not let your product code "pollution" "pollution" is tested. In this example, we will establish a GUI-based test environment. In VC, we build a dialog-based Project. Don't forget the correct LIB of LINK. In this case, we use static cppunit lib. Since we want this Project running to display the interface of Figure 2, we need to block the original dialog box in the AppAnce (), in order to CPPUNIT's GUI. CPPUnit :: MFCUI :: Testrunner Runner; runner.addtest (plustest :: suite ()); // Add test
Runner.run (); // show ui
/ *
CCPLUSTESTDLG DLG;
m_pmainwnd = & dlg;
INT nresponse = dlg.domodal ();
IF (NRESPONSE == iDok)
{
// Todo: Place Code Here to Handle When The Dialog Is
// dismissed with ok
}
Else IF (nresponse == idcancel)
{
// Todo: Place Code Here to Handle When The Dialog Is
// dismissed with cancel
}
* / In front, we mentioned that Testrunner outputs the dialog box in Figure 2, which is why we want to set environment variables for the path to Testrunner.dll. Note: Plustest :: Suite () Returns a pointer to CPPUnit :: test. This pointer is the starting point of the entire test. CPPUnit :: TestFactoryRegistry :: getRegistry () Returns the TestFactoryRegistry factory according to the name of TestSuite, and then calls MakeTest () in the factory to assemble the TestSuite. This is a recursive call, which will establish a tree test structure. Namespace Plustest
{
CPPUnit :: test * suite ()
{
CPPUnit :: TestFactoryRegistry & registry =
CPPUnit :: TestFactoryRegistry :: getRegistry (Plussuitename ());
Return regiSTRY.MAKETEST ();
}
} Don't forget to add header files: #include "cplustestsuite.h" #include
{
CPPUNIT_TEST_SUITE (CPLUSTESTCASE); CPPUNIT_TEST (TestAdd);
CPPUNIT_TEST_SUITE_END ();
PUBLIC:
CPlustestCase ();
Virtual ~ cplustestcase ();
Void testAdd (); // Test method
}; Have you seen these many macro? They have a big hand. CPPUNIT_TEST_SUITE (CPLUNIT_TEST (TESTADD); cppUnit_test_suite_end (); Through these macros, we register CPlustestCase and TestAdd to the test list. In addition, we need to add additional Cpp file a macro: CPPUNIT_TEST_SUITE_NAMED_REGISTRATION (CPlusTestCase, PlusTest :: plusSuiteName ()); it CPlusTestCase this TestSuite registered to a specified TestFactory factory, this TestSuite with PlusTest :: plusSuiteName () function returns The name is logified (the Suite () function introduced earlier is through this name). Plussuitename () is a function under this Plustest's nameSpace, which returns to our name created for this TestSuite (this example we are named "Plus"). In fact, we can also do this, you can write "Plus" directly in Hongli. But this can prevent the trouble of hard coding. In the test class, we added a test method: void test (); it tests the object of the previous CPLUS class: int Add (int NNum1, int nnum2); let's see its implementation: void CPlustestcase :: TestAdd ()
{
CPlus Plus;
INT NRESULT = Plus.Add (10, 20); // Execute Add operation
CPPUNIT_ASSERT_EQUAL (30, nresult); // check the result equal to 30
} CPPUnit_assert_equal is a macro of a judgment result. Similar other macros in CPPUnit See Testassert.h, this article does not detail here. In addition, we can override the setup (), Teardown () () two functions of the base class. These two functions are actually a template method. When the test is running, setup () will be called for some initialization work. After the test, Teardown () will be called to do some "good work", such as resource recycling, etc. . Of course, you can also override these two functions because they are defined in the base class into an empty method, not a pure virtual function. In addition, the header file is to be added in the CPP: #include "plussuite.h" 4, after writing the product code, after writing the product code, compiled after the above test code is written. Compiling affirmation, but the compiler will tell us that the CPLUS class has no statements, because we have not implemented the CPLUS class yet! The current job is to implement the CPLUS class immediately, let the compilation pass. Now you should smell a little "test driver" taste? Built a MFC EXTENSION DLL in the VC, add class CPLUs in this Project, which is as follows: Class AFX_EXT_CLASS CPLUS
{
PUBLIC:
CPlus ();
Virtual ~ cplus (); public:
Int Add (int NNum1, int NNUM2);
}; There is only one way to test the method to test by our test code. Take a look at its implementation: int CPlus :: add (int nnum1, int nnum2) {
RETURN NNUM1 NNUM2;
} Is very simple, isn't it? Now let the previous item contain the Project Dependent this project, include related header files, Rebuild All, and you will find compilation. Have you experienced the test code driver product code? Of course, our example is still very simple and does not refactor this step. When you run our test program, you will see the interface as shown in Figure 6:
Figure 6
Click "Browse", as shown in Figure 7:
Figure 7
This should be deeper about the name of the tests we say before. Plus is a test package TestSuite, which contains a test case that includes a test method below. At this point, we have a detailed introduction to the application of the CPPUnit test framework, hoping to help you in the TDD process. Reference: CPPUNIT Source Code and Description Document CPPUnit Test Frame Getting Started (1)
