Quick Guide for CPPUnit under C Builder
First, unit test and cppunit
1.1 What is CPPUnit
Unit testing is a program that can be used automatically and test source code in a batch. Unit test test a small piece of code or a sufficiently small function. The unit test program calls this small piece code or function and verifies whether the return result meets the result of the predetermined result.
Generally, the developer is responsible for writing and maintaining the test unit. Unit tests are often used to test the following: boundary, abnormal data type, interface between components, and complex operations that require constant test when software changes. Unit tests should be run regularly during software construction.
1.2 What is CPPUnit
CPPUnit is a LGPL-based open source project, the initial version transplantation from JUnit, is a very excellent open source test framework. CPPUNIT and JUnit are the same ideas comes from XProgramming. The main function is to manage unit tests and automate tests. This describes the powerful power of the test framework. Do you have the following questions during the development process? If the answer is affirmative, you should learn to use this technology:
l Test code is not well maintained, and it needs to be rewritten again when you need to test;
l In put too much energy, find bugs, and new code still appears like bugs;
l After writing the code, there is no bottom in my heart, whether there is a lot of BUG waiting for yourself;
l The newly modified code does not know if it affects other part of code;
l Due to too much involve, it is not dare to modify the code;
l ...
Second, CPPUnit
2.1 Basic Principles
The first thing we have to write test code is to verify the correctness of the code or debug BUG. When writing test code, there is a targeted, for those who are easy to make, volatile written test code; without writing test code for each detail, of course, unless there is excessive or reliability requirements.
The relationship between encoding and testing is inseparable. The recommended development process does not need to be tested after writing all or a lot of code, but is completed in part of the code, such as a function, followed by test code for verification. Then write some code, write the test. Each test is done over again. The advantage of doing this is that the code is finished, and the basic test is over again, and the heart is confident in the code. Moreover, the old code is constantly tested when writing new code, and the impact on other partial code can quickly discover, position. The process of continuously encoding the test is also the process of maintenance of test code so that the test code has always been effective. With the guarantee of each part of the test code, there is a mechanism for automatic testing, and there is nothing concerned about the previous code. In extreme programming (a software development ideology), even emphasize the test code first, then write code that meets the test code, and then complete the entire software.
Based on the purposes, ideas, the following summary of the principles of unit testing during the usual development process:
Write the test code first, then write code that meets the test. After the completion of the partial code, complete the corresponding test code;
The test code does not need to overwrite all details, but there should be corresponding test cases for all major features and possible places;
Discover BUG, first write the corresponding test case, then debug;
Constantly summarizing the causes of bugs, write corresponding test cases for other code;
Each time you write complete code, run all previous test cases, verify the impact on the previous code, eliminate this effect as soon as possible; constantly maintain the test code, ensure the code changes after the code;
Have the above theory to guide, test behavior can be ruled. So how CPPUnit implements this test framework to help us manage test code and complete automatic testing? Let's take a look at the principles of CPPUnit.
2.2 Principle of CPPUnit
In CPPUnit, a test object for one or a set of test cases is referred to as fixture (facilities, below for easy understanding of the English name). FixTure is the target being tested, which may be an object or a set of related objects, or even a function.
With fix, you can write a test code for a function of this fixture, a possible error process, which is called TestCase (test usage) for a complete test of a certain aspect. The steps that usually write a TestCase include:
Initialize FixTure, and other initialization operations, such as: generating a set of tested objects, initialization values;
Fix FixTure according to a function you want to test or a process;
Whether the verification result is correct;
Clean up for FixTure and other resource releases.
Multiple test cases for FixTure, usually (1) (4) part of the code is similar, CPPUnit introduces SETUP and TEARDOWN virtual functions in many places. You can complete (1) initialization code in the setup function, and complete (4) code in the Teardown function. In the specific test case function, only the (2) (3) part of the code is required, and the runtime CPPUnit will automatically run the setup for each test case function, then run TEARDOWN, so that there is no crossover between the test cases.
All test cases for FixTure can be encapsulated in a subclass of TestCase (naming conventions are [classname] testcase). Then define this fixture's setup and Teardown function, define a test function for each test case (naming convention is Testxxx). Here is a simple example:
Class Mathtestcase: Public Testcase
{
protected:
INT M_VALUE1;
INT m_value2;
PUBLIC:
Mathtestcase: Testcase (name) {}
Void setup ();
Static Test * Suite ();
protected:
Void TestAdd ();
}
Void Mathtestcase :: setup () // Initialization
{
M_Value1 = 2;
M_Value2 = 3;
}
Void Mathtestcase :: TestAdd () // Test the test function
{
// Step (2), operate FixTure
Double Result = m_value1 m_value2;
// Step (3), whether the verification result is for Assert (Result == 6.0);
}
// Nothing clean job does not define TEARDOWN.
During the test function, the verification of the execution result is successful or failed to directly reflect the success and failure of this test case. CPPUnit provides a variety of ways to verify success failure:
Assert (condition) / / is confident that Condition is true
/ / Judgment the Double EXPECTED value and the actual value, Delta is allowed to deviate
AssertDouBleasequal (Expected, Actual, Delta)
/ / Judgment the long shape EXpected value and whether the actual value is equal
askERTLONGSEQUAL (Expected, Actual) // Current test failed, and prints Message
When the test code that eventually runs the entire application, you may need to run multiple test functions to a Fixture at the same time, and even multiple fixture test cases. The collection of this simultaneous test case is called TestSuite in CPPUnit. Testrunner runs test cases or TestSuite, and manages the life cycle of all test cases.
Here is an example of Testrunner:
TestSuite * TestSuite = New Testsuite ("Mathtestcase");
// Add a test case
TestSuite-> AddTest (New TestCaller
"TestAdd", & Mathtestcase :: TestAdd);
/ / Specify running Testsuite
Runner.addtest (TestSuite);
// Start running, automatically display test progress and test results
Third, how to apply CPPUnit in C Builder
CPPUnit uses standard C development, which can be applied to a variety of operational platforms such as Windows, Linux, or IDE such as Visual C and C Builder. Let's introduce how to use CPPUnit in C Builder.
On the official website of CPPUnit, only DLLs for Visual C are provided on the official website, and there are detailed guidance manuals, most of the online article also describes how to integrate CPPUnit in the VC. Compared to C Builder is a lot of cold, it is still a C Builder fans who are not fat, and provides CPPUnit GUI that can be used for C Builder.
Download this file from the Internet, expand the file, the directory is as follows:
Where cppUnit15projectgroup.bpg is an engineering group file, the TEST directory contains the test framework. The project provides graphical interface under Borland Displays test cases and test results, and the Samples directory contains sample programs. This project is created with C Builder3, the test framework included is also cppUnit1.5 (current CPPUnit is 1.9), which may be a bit out of date. Take it, it is good enough ... Here is a simple example in combination with a simple example, describing how to create your own test case.
3.1 Creating a test case
There is a hostApp subdirectory in the Borland subdirectory, which contains HostApp projects. This project is the host of our test case, we will add test cases to this project. Before adding the case, you must first need to specify the object fixture, and then determine the test case based on its function, process, and previous experience. This step is very important, directly related to the final effect of the test. Of course, the process of increasing the test case is a phased job. After starting the code, complete the test case of the function, to ensure its completion function; then combine the previous experience (such as boundary value test, path overlay test) Write test cases; finally, the test case is completed according to BUG when discovered related bugs. For example, test the integer addition, first define a new TestCase subclass, MathTestCase, write test code for test cases. When you need to add a new test case, you only need to add a new test function to modify Setup and Teardown as needed. If you need to test new fixture, define a new TestCase subclass.
3.2 Management test case
Organize test cases that need to be tested into TestSuite and run through TestRuner. This part of the code will be changed much when adding a new test case. Just add new test cases to TestSuite. The specific method is to open the hostAppUnitform.cpp file, add the following code before the StartTesting () method of the StartTesting () method:
TestSuite * TestSuite = New Testsuite ("Mathtestcase");
TestSuite-> Addtest (New Testcaller
Runner.addtest (TestSuite);
3.3 Operation test case
Run Hostapp.exe, then the following interface occurs:
All TestSuite and TestCase will be listed on the tree node, select one of the TestSuite or TestCase, then click the RUN button to start the test case, the number of test cases that run, the number of modes of failure, and the number of errors. The bottom StatusBar also displays the execution time of the test case. If there is no test case fail, the progress bar will be expressed in green, as shown in the figure:
If the test fails, the progress bar is red, and the following list will list the error type, the test case name, the condition of the failed use case, the failed statement is the line number and file name of the file.
3.4 suggestion
Typically contain test sample samples and test objects are in different projects. TestCase should be written in another project (preferably in different directories), and then the object being tested is included in the test item.
[reference]
· Li Qun, "Convenient Development Tool CPPUnit Quick User Guide"
· CPPUnit homepage
CPPUnit Cookbook
· Xprogramming homepage
· Martin Fowler, "Reconstruction - Improved Code Design"
