JUnit actual combat article (1)
Amender: Huang Kai
E_mail: hk_sz@163.com
Foreword
Since the company is now undergoing Unit Test Case, it is aware of JUnit. The following is the collection of all the people's strengths (considering the summary of my idea, maybe not fully express the author's idea, so In the appendix, there is some article address I refer to, everyone may wish to see the original text).
First, the concept of test
For a long time, the software developers I have been in contact have rarely test work in the process of development. Most of the projects are written in test documents in the final acceptance, and some projects have no test documents. Now there is a change. We have been advocating UML, RUP, software engineering, CMM, with only one, improve the quality of software preparation. Extremely an extreme example: If you are a super programming designer, a legendary figure (you can listen to music while listening to music while writing this operating system, and within two days finished!). I really admit that there is such a person (the guy who writes the VI editor in UNIX is this kind of person). It is very unfortunate that these fans have not left anything about how to repair the fruit, so we can only focus on several points at the same time (according to scientific statistics, I don't believe, general People can only consider up to 7 or so, the master can reach 12 or so), not only to overview the overall understanding of details - can only expect other ways to ensure the quality of the software we have written.
To explain how our mortals are stupid. There is a smart person proposing the concept of software entropy: starting from a very good state of the design, as the new features continue to join, the program gradually lost the original structure, eventually become a group Mess. You may argue, in this example, the design is very good. It is actually not good. If it is good, you will not happen. Yes, it seems that you become smart, but you should also pay attention to two questions: 1) We can't expect the structure of the Dinosaur Era (prior to ten years ago) to design it now; 2) Have a signature right Customer representatives can ignore whether a new feature will have an impact on the structure of the software, even if there is an impact on the problem that programming staff needs to consider. If you refuse to join this new feature you think is deadly, then you are likely to lose your housing loans and bread (for Chinese engineers, maybe it is rice or noodles, you must see you is a South or a northerner).
In addition, it is necessary to explain that some of the books I have seen have not written so people (I am sorry ...). I hope to see the brothers and sisters of this article can easily accept the concept of tests and put them into implementation. So some places have some exaggerations, welcome brothers and sisters who have an in-depth understanding of tests, they can enlighten me.
Ok, we are now going to be correct. To test, you must understand the purpose of the test. I think the purpose of the test is simple and attractive: writing high quality software and solving software entropy. Imagine, if you write the software and Richard Stallman (the head of the GNU, FSF), is there a sense of accomplishment? If you have been maintaining this high level, I guarantee that your salary will change.
Test also classified, white box test, black box test, unit test, integrated test, function test .... We have never, how to classify, how to classify. First, those who are useful for us, about other tests, interested people can refer to other information. White box test refers to the tests made under the conditions that the software knows how to complete the function and what to do (what). It is generally done by the developer. Because developers understand the software you have written. This article is also based on white box test. The black box test refers to the tests made under the conditions that the software that is tested is tested. It is generally done by testers. Black box test is not our focus. This article is mainly concentrated on unit testing, and the unit test is a white box test. The purpose is to verify that one or a number of categories are working properly as designed. Integrated testing is to verify that all classes can cooperate with each other, collaborate to complete specific tasks, and we are currently not concerned about it. The test I mentioned below unless specifically described, it is generally a unit test. It is important to emphasize that the test is a continuous process. That is to say, during the entire process of testing and development, the unit test is particularly suitable for the development process of iterative incremental type (ITERATIVE AND INCREMENTAL). Martin Fowler (a bit like a reference to the word) or even think: "You should not write the program before you don't know how to test the code. Once you have completed the program, the test code should also be completed. Unless the test is successful, you can't think You have written procedures that you can work. "I don't expect that all developers can have such a high sense, this level is not one. But once we understand the purpose and benefits of the test, we will naturally insist on introducing tests during the development process. Because we are testing novices, we also ignore those complex test principles, first say the simplest: test is whether the expected result is consistent with the actual results. If the consistency passes, it will fail. Look at the example below:
// The class that will be tested
Public Class Car
{
Public int getWheels ()
{
Return 4;
}
}
// Class to execute the test
Public Class TestCar
{
Public static void main (string [] args)
{
Testcar mytest = new testcar ();
Mytest.TestGetWheels ();
}
Public void testGetwheels ()
{
INT EXPECTEDWHEELS = 5;
Car mycar = new car ();
IF (expectedwheels == mycar.getwheels ())
System.out.println ("TEST [CAR]: GetWheels Works Perfect!");
Else
System.out.println ("TEST [CAR]: GetWheels Doesn't Work!");
}
}
If you write the code immediately, you will find two questions:
First, if you want to perform the test class TestCar, you must have to manually knock into the following command:
[Windows] D: /> Java TestCar
[UNIX]% Java TestCar
Even if the test is as simple as exemplified, you may not want to type the above command at each test, and you want to click on an integrated environment (IDE) to execute the test. The following chapters will be introduced to these issues.
Second, if there is no certain specification, the writing of the test class will become another standard that needs to be defined. No one wants to see how others design test class. If everyone has different design test classes, light maintenance is tested enough, who is still maintaining test class? There is another point I don't want to mention, but this problem is too obvious, the test class is more than the class being tested! Does this mean this double work? Do not! 1) No matter how complex the getWheels method of the test class-Car, the test class-TestCar's TestGetWheels will only maintain the same amount of code.
2) Improve the quality of the software and solve the problem of software entropy is not cost. TestCar is the price.
What we can do now is to minimize the consideration of the payment: The test code we have written must be readily read by maintenance personnel. We have a certain specification to write test code. It is best to support these specifications. Ok, what you need is JUnit. An Open Source project. In the words of its homepage, "Junit is a regression test framework written by Erich Gamma and Kent Beck. It is used for Java developers to write unit tests." The so-called frame is Erich Gamma and Kent Beck. Take some of the box boxes, you must follow this bar box: inherit a class and implement an interface. In fact, it is the specification we mentioned earlier. Fortunately, JUnit is currently recognized by most software engineers. We will get a lot of support to follow JUnit. The regression test is to test the code written: write some, test some, debug some, then loop this process, you will continue to repeat the previous test, even if you are writing other classes, due to software entropy Existence, you may find that a certain operation of the fifth class will cause failure of the second class when you write a fifth class. We grab this big bug by regression test.
Second, JUnit Introduction and Why use Juint
JUnit is a Java framework for unit testing of the program code. The programmer can ensure that the small amount of changes in the code will not undermine the entire system after testing the code after each modifying the program. If there is an automation test tool such as Junit, the repeated test of the code simply exhausted people and may not be accurate. Now, the test process can be carried out frequently and automatically, so you can minimize the program error. It writes a unit test: the white box test in the software engineering is the function of testing a certain method of a class. Test First Design, which is respected in XP is based on the above technology.
If you want to write a code:
1. Write test with JUnit, then write the code
2. Write code, run test, test failed
3. Modify the code, run the test until the test is successful
If you modify the program, you will be able to run the test code again, if all the tests are successful, the code modification is completed.
TEAM development under Java, generally adopting CVS (version control) Ant (project management) JUnit mode:
1. Work every morning, each developer gets a copy of the entire project from CVS Server;
2. Get your own task, first write the test code for today's task;
3. Then write the code of today's task, run the test until the test passes, the task is completed;
4. One or two hours before get off work, each developer submits the task to CVS Server; 5. Then run automatic testing throughout the project, which test error is found, and find relevant personnel to modify until all tests pass. Get off work ...
Write tests first, write the code again:
From technology to force you to consider a class of features, that is, this class provides an external interface, not too early to fall into its details. This is a design principle that is advocated. A good test is actually a good document, which can often understand its functionality by viewing the test code of this class. Special, if you get a program of others, write testing is the best way to understand the functionality of this program. The principle of XP is Make IT Simple, not recommended to write another document, because the project is often changed during the development process, if the document is written in the early stage, there is a synchronization document after the code changes, more work, and due to project time The incomplete or inconsistent with the document is inconsistent with the code, and it is better not to write. And if you write a document after the project, developers often have forgotten all kinds of considerations when writing code, and there is the pressure of the next project, and managers are not willing to write documents for the old project, leading to future maintenance. No one can guarantee that the demand is not changed, and the past projects often have a big headache to the demand, and this change will bring other places. To this end, in addition to the design of the design to split items (loosely coupled), but if there is a test, a good test framework has been established, and the change is modified, if the code is modified, just re-run the test code, if The test passed, and it guaranteed the success of the modification. If there is an error in the test, it will immediately discover the wrong, modify the corresponding part, and run the test until the test is fully passed.
There is often a contradiction between development and test sectors in software companies: Due to the development and testing of two departments, there are more communication costs and time, communication tends to generate errors. And it is very easy to form a strange circle: Developers who throw it to the testers in order to drive the task, then write other tasks, the test is of course failed, and take the code back to rewrite, and The department that is the worst technology that is often a software company technology is that the test department (good people go to write code), and the test has become a headache. The root cause of this strange circle is the unclear, according to the provisions in XP: people who write this code must write tests for their code, and only have the test, only to complete this task (here the tests include all tests, if testing When you find that your program causing the test failure of other modules, you have a responsibility to notify the relevant personnel to modify until integrated test passes), which avoids the occurrence of such problems.
reference
JUnit implementation
Author: eric site: http: //www.neweasier.com/article/2002-08-07/1028723459.html
How to use JUnit Framework to write unit testing
Author: cinc site: http: //www.chinaunix.net/bbsjh/14/546.html
It is mainly to reference CINC's comments. As for Mr. Shen Wenbo's "How to use JUnit Framework for unit testing" original text I suggest that everyone has time to look at it, write very well, I have not integrated here.
Create a JUnit test case
