Unit test is a test method for conducting behavioral verification for classes, methods, etc. To give a simple example: If you need to test a accumulated function Int sum (INT K), the unit test is made to give this function different input, and then verify whether the corresponding output meets the requirements. For SUM (INT K), give him some inputs, these inputs should satisfy people's brain strange ideas, which can be SUM (0); SUM (5); SUM (-5); SUM (5.1234 ); For these inputs, it is possible to confuse, but the human brain cannot be, he wants to give the expected results after each input, then compare the function output to determine the function run within the expected range. This is a unit test, simple, clear.
The unit test has been in the cold palace developed by the software, and the reason is probably the problem of ideology. If you ask developers: Why don't you use a unit test? The answer to the answer ten is eight nine is this mode: write code time is not enough to do it. (I just also belonging to one of that eight nine) However, there is a conclusion: Write unit test saves development time. This may be incredibly, but after the body, it is true, but there is a premise: in the code before the code. Very a bit of a charm. In the Heroes Island, many Central Plains Top Territory Receive "Herbal" can not be able to see the essence of martial arts. Many things are often like this. According to the normal branch, they will change the clouds in the direction. And said that the code to be written is like the martial arts of Shaolin Temple. It is necessary to pass the test of Shaolin. Many of the monks are in the copper people because of a magnificent imperative, it is everything. How can I pass the test of the copper? If you understand the copper gap from the beginning of practice, and in practice, you will continue to get torture, then the last pass will not be a problem. In the above guiding ideology, the test case is designed before writing the code, then write code, this is the benefit of doing this: From the beginning, you understand what the purpose is, for the code will be tortured to the chest, The term is said to be: the demand is clear, the code coverage is high. My personal experience is reduced after using this method, and it is hard to reduce the probability of low-level errors. Now, it is a matter of doing a piece of merits that are nothing to do with the Kent Beck master. There is also an advantage that the resection is improved. This benefit argument is a little sophisticated, first, the code itself has a user, that is, the code we need to implement, and another user comes from test cases, so this code itself is reused. It is stronger. This point has to be acknowledged that when writing a test case, it will not consciously consider embedding in the software, therefore, in this case the design will have a lower coupling. It is important to compare the test driver with the classic first code. It is important to be different. The write code is your own flesh, no one will hope that it is fragile, and it is not willing to see its failure. Therefore, when testing, it is often surprised, the finger is hovering above the back-back button, the tightening nerve frequent acceptance test . For test drivers, born in a hard environment, work hard every day, is to be able to get out, grow into a strong code, so we will do not hesitate to press the Enter key, let the storm are more fierce!
It is important to keep it the melody during the test drive. It is like a wonderful movie, there is a low-spirited trough, and there is a climax of passion. The melody for test-driven development is: Design test cases, written the least code, and design the next test case. Among them, the process of writing code through testing and reconstructing code often requires several iterative processes, during which they are ups and downs, and exciting. After designing test cases, it is compiled, and it will encounter the first trough: Compile error. Our efforts are compiled. At this time, we write the least code to compile, which ushered in the first rising period, but will face the problem that the test cannot be passed, so it will make persistent efforts, increase the function of the code, this, this, We passed the test and ushered in the first climax. Good things always need to become better, so we started to trim, make it more elegant, we don't allow any repetition, Copy & Paste is our dead enemy, not allowing code that you don't understand, it is an obstacle to understand No unfresh taste is floating from the code. Reconstructing will help us have fulfilled perfect, and all the cost is just a few minutes. However, don't worry, otherwise it will be burn the tongue. Step by step, each modification must guarantee the test before passing so, we will eventually reach the other side of happiness!
People are inert, inert is often associated with failure, and the error is linked together. However, inertia has also a lot of benefits. It is an example in which it is reversed. In the process of using the test drive, if each test requires an environment and output format of the organization, and the data flying on the screen is compared, then the hard-working person can not adhere to this work, and the test driver will also become A beautiful aerial pavilion. To give full play to the power of test drivers, you must have the following "necessary non-adequate" conditions: convenient to establish a test environment; there is a good output form; convenient comparison test results. With the above conditions, people can establish a test environment between the bomb fingers, conduct frequent tests, let their code accept frequent tests in front of the mountain. Junit is a set of unit test frames in a Java environment established by the Kent Beck master. It meets the necessary conditions for the above test drive, providing a convenient test environment, good screen output, and result comparison mechanism. Although JUnit is Java, the test drive is all developers. CPPUnit can meet their requirements for people walking in the CPP world. CPPUNIT is Michael FeatherS to establish an open source unit test library, which is a C version of Junit, which also provides convenient conditions. Its old nest is located at http://sourceforge.net/projects/cppunit/. Before applying CPPUnit to test driver development, you must first make a few concepts: cppunit is tested in hierarchy. The bottom is Test Case, here is where the test code exists, in other words, it is the test function. After having a few Test Case, you can organize them into test fixture. In Test fixTure, an instance of the class being tested is created, and Test Case is written to test the class instance. Test Suite can be used to manage the test when there are multiple Test fixTure. Borrowing an example on CPPUnit, you need to design a plural class. First, you want the complex class to use "==" to determine, so first conceive a Test Case: Class ComplexNumbertest: Public CPPUnit :: Testcase {
PUBLIC:
ComplexNumbertest (std :: string name): CPPUnit :: testcase (name) {}
Void runtest () {
CPPUNIT_ASSERT (MyComplex (10, 1) == Mycomplex (10, 1)); // Note: 1
CPPUNIT_ASSERT (! (MyComplex (1, 1) == MyComplex (2, 2)))); // Note: 2
}
}
The intent of this test case is obvious, that is, the MYCOMPLEX class is equally tested. According to the multiple mathematical knowledge, it is possible to get Note: 1 we expect to wait, and Note: 2 is not equal. With this test case, compile it, because the MyComplex class does not define, it will not be compiled, but this is the problem that will be encountered in unit testing. For those who cannot be compiled, let us complete the following code as soon as possible:
// if we compile now, We get compile error.so Keep fixing it.
Bool Operator == (Const mycomplex & a, const mycomplex&&)
{
Return True;
}
// Now Compile It Again, OK! Run it, we'll get some fail.//this is because the Operator == () Doesn't Work Properly.keep Fixing IT.
Now there is no problem, you can breathe, but you can't pass the test, so you will continue to work, write:
Class mycomplex {
Friend Bool Operator == (Const Mycomplex & A, Const MyComplex & B);
Double Real, Imaginary;
PUBLIC:
Mycomplex (Double R, Double I = 0)
: Real (R)
Imaginary (i)
{
}
}
Bool Operator == (Const mycomplex & a, const mycomplex&&)
{
Return a.real == B.Real && a.imaginary == B.Imaginary
}
// if we compile now and run Our test it will pass.
Compile, test, adopted, this world is quiet, like a peach blossom source ...
However, we have to do a good, Mycomplex is not beautiful enough, so I changed a name ccomplex, this big success, but my heart has always had a knot, how to use it in my own project? If you want to know the matter, please decompose down.
references:
Wiki About TDD
http://c2.com/cgi/wiki?testDrivendevelopment
UnitTests in extremeprogramming.com
http://www.extremeprogramming.org/rules/Unittests.html
CPPUnit Wiki
Http://cppunit.sourceforge.net/cgi-bin/moin.cgi/frontpage
CPPUNIT COOK BOOK
Http://cppunit.sourceforge.net/doc/lastest/cppunit_cookbook.html
