Feeling test driver development
From: Tianji Forum
Author: Xu Feng
Software Development Methodology Thai Kent Beck Mr. Kent Beck is the most advocated "mode, extreme programming and test drive development". In the ultimate programming (XP) method of his creation, it is recommended that "test first" is "testing first", and also writes a book "test-driven development" book, detailed explanation. Test driver development is an important feature of extreme programming. It promotes the development of the code with continuous testing, thereby achieving both code and ensuring quality.
I saw the name of "testing first" and "test driver", deeply aroused my strong curiosity and started his exploration ..
1. The soul shocks
Learning for a while, I have been deeply shocked. The original method actually so stupid I face the test first this name, the biggest question is "the program has not written it, what is it tested!" Later, I thought, in fact, this is a muddyman understands the truth, but it is in painting. Let's take a look at how two different muddyers work:
Craftsman 1: Drapping a horizontal line, compares each of the horizontal lines, making each tile remain horizontal.
Craftsman Two: First put a row of bricks, then pull a horizontal line to see which bricks have problems, and then adjust.
What kind of work will you choose? You will definitely blame the craftsman! This is a waste of time! However, you think about it, how do you do it when you write a program? We are working on the method of craftsman! Even sometimes more stupid than the craftsman, the entire wall is finished, directly "integrated test", often let the entire wall collapsed. See here, do you still feel that your method is high?
The unit test has been neglected for a long time.
Every programmer knows that you should write a test program for your code, but it is very little to do. When people ask why, the most often heard the answer is: "Our development is too nervous." However, this has led to a vicious circle, the more no time to write the test program, the worse the code is getting worse, the flowers are looking for bugs, and the time to solve the bug is more and more, the actual efficiency is greatly reduced. Since the efficiency is lowered, the time is more tension and the pressure is large. Do you think, why not pull a horizontal line? Isn't it possible to spend the time of launching time in unit test, making our procedure more robust, more easy to modify? Abandon the original trick!
Our automation level is too low
Some people will explain that that is because the pull of the pull of the pull of the pull is very simple, and the writing test procedures are very complicated. I have been doing it to this sentence itself is not available. However, it also reflects a new problem, we need to make more convenient, time-saving methods.
To test a class, the easiest way is to use an expression to observe the value and status of the object directly in the debugger, you can also add some assertions, print intermediate values, etc., of course, can also write a specialized test program. However, these methods have a large limitations, and they need to join artificial judgment and analysis.
As a result, the introduction of the automated test is the way to solve. It is because of this, advocating the "test-driven development" population, develops a series of automation unit test frames XUnit, and now there is already a test framework for various common languages such as Java, Pyhton, C , PHP. This is enough to probate those developers who are "preparing test code too much trouble", so that they have no reason to escape unit testing.
Just as Robert Martin said: "The more simple running of the test suite, the more frequently run them. The more you test, the more you discover any departure from those tests. If you can run all the tests multiple times a day Then, then the failure time of the system will never be more than a few minutes. " 2. Recognize the test driver development
The test drive development theory is initially stems from thinking about these issues:
1) What if we can perform a test plan before writing a program code?
2) If we guarantee that this function will not be implemented in the program unless this feature will result in failure, it will not implement this function in the program.
3) For an angle, if you find a feature when you test, you must increase this feature, what will we add this feature?
Through the practice of these problems, masters have found that this is indeed a good starting point for improving software code quality and making efficiency.
Software development with such ideas, ensuring that each feature in the program has tests to verify that it is correct, and whenever the function is unintentionally modified, the test program will find. At the same time, we also have a new observation point, observe our procedures from the perspective of program-programs, so that we can also protect the interface to the interface, making It is easier to be called. In addition, the code under this idea will become easier to call, and it must maintain low coupling with other code. And, when you want to multiplex these modules, the test code gives a good example. All this makes the quality of software development work.
Therefore, the essence of test-driven development is: the test plan design work is advanced in advance, to do this before writing code; verify the design, derive design from the perspective of testing; at the same time as the test plan as a criterion, effectively Using each step prepared by its inspection code, verify its correctness in real time, and realize the "small step" of the software development process.
3. Practical test driver development
Below, I will explain how to "test drive development" in combination with an actual small example. This example was developed in the J2SE SDK 1.4.2 environment, as well as the supporting tool JUnit 3.8.1.
Mission brief
The queue is a very common data structure in program development, where I will describe a class-queue that implements a queue function as an example. This class will achieve the following basic operations:
Judging whether the queue is empty: EMPTY ()
Insert the queue (ie adding a data element at the queue): inQueue (x)
Export queue (that is, delete the team's first data element): Outqueue ()
Take a column (that is, the value of the reader queue first data element): GetHead ()
Empty queues (that is, completely delete all data elements of the queue): CLEAR ()
Query X in the queue: Search (x)
Test case analysis
In test-drive development practice, the first step is to consider the test plan, and we can get the following test case by analyzing the function of this class:
1) Team is empty test
TC01: When the queue is new, it should be empty;
TC02: After the queue is cleaned, it should be empty;
TC03: When the number of queue operations is the same as the number of inserted queues, it should be empty; 2) Insert the queue test:
TC04: After inserting the queue operation, the new data element will insert the unlucky of the queue;
TC05: After inserting the queue operation, the queue will be no empty;
3) Export queue test
TC06: After the queue operation, the first data element will be deleted from the queue;
4) Take a team head test
TC07: Take a team header will get the first data element in the queue.
5) Empty queue test
TC08: After the queue operation, the queue will be an air queue;
Note: In order to explain this, all test cases are not listed, and some simple test cases have been selected.
First iteration
We first prepare the first test code, this test code only considers the test case TC01, which is to ensure that the new team is empty:
Installing JUnit is very simple, just need
Download the latest package (zip format) in www.junit.org, then decompress it, and add "junit installation directory / junit.jar" and "JUnit Installation Directory" to the system environment variable ClassPath. .
The execution kit can be used in the main method like the above program, or you can call directly in the command line: java junit.textui.teestrunner test class name (text format), Java junit.awtui.teestrunner test class name (graphics format, AWT version) ), Java junit.swingui.teestrunner test class name (graphic version, swing version).
Compilation execution (ie execute javac testqueue.java and javaac testqueue.java and javatestqueue), you will find a prompt on the screen:
.E a small point description executed a test case, E indicates that it failed
Time: 0.11 Description Execution Test is a total of 0.11 seconds
There Was 1 error: Description There is an error
1) TESTEMPTY (TESTQUE) java.lang.noclassdeffounderror: Queue
At testqueue.setup (testqueue.java: 13)
At testqueue.main (Testqueue.java: 9)
Failures !!!
Tests Run: 1, Failures: 0, Errors: 1
The test did not pass it, because the Queue class has not been written yet? How can we pass the test, so we write the following code to pass the test:
After compiling this class, execute the test program again, then the following prompt will:
A small point illustrates a test case, no e means its success
Time: 0.11
OK (1 test)
You can also use the other two commands we said before so that the test feedback is reflected in graphical form, for example, executing java junit.awtui.teStrunner TestQueue, will appear:
Figure
3-1
Second iteration
Next, we modify the test program, join the test case TC04, TC05 considerations.
According to this test code, we need to add two methods in queue () and Search () in the Queue class, as follows: After compiling, execute java junit.awui.teStrunnerTestQueue again, you will see the successful green.
Figure
3-2
Running success
Let's take a closer look at this interface.
1) The top list lists the class name of the test code. There is a "Run" button on the right. When you need to run this test code again, simply click this button. In addition, it is useful to hook the "RELOAD CLASSEVERY RUN" option. When you test the pass (when there is a red), you can turn around to modify the code. After the modification, just press the "Run" button to run again.
2) The intermediate area is a state report area, and the red represents unauthorized, and the statistics have been running a total of more tests (that is, the number of methods in the TestCase class).
3) If there is an error in the test, for example, we don't careful "Asserttrue (! (Q2.empty ()));" Written into "Asserttrue (Q2.empty ());" will cause test failure:
Note: Since the first test is still passed, you will see a green bar. At this time, you will find that Junit will list the error, and the corresponding "Run" button is also bright, indicating that you can turn your modifications, then click this "Run button", you can just fail This test will save a lot of time.
At the same time, in the bottom of the following form, the detailed reason for failure is listed.
Figure
3-3
Failed state
Back iteration
Here, the development has not been completed, but this kind of thinking has passed through such two short practice, and everyone will try it.
In addition, it is worth mentioning that although the ocean sprinkles a large article, I will have it for less than 15 minutes. Moreover, when you see a green strip, your heart is very comfortable.
4. Some regrets
The article will tell a paragraph here, but some regrets.
Regrettab: This is just an article, there is no way to talk to all aspects, so that everyone may not be able to go up.
It is because of this reason, this article named "sentiment", exchanges with you, hoping to help you better accept the philosophy of "test-driven development" and began to practice.
Regret 2: The author's level is limited, and you cannot solve all the problems of everyone.
What is the "test driver development", "agile software development", "hug changes: resolution limit programming", recorded these answers. Although the road is difficult, the teacher has already.
Practice is always the best way to learn, see the author's feelings, start the limit of the limit, because there is unlimited scenery, fun is unlimited. When you master the essence of test-driven development, you can confidence in all the code you have written by you, no longer worry when you put a cold arrow behind you, say goodbye to this, bring you unlimited pressure.
