Unit test for Java programs __java

1. Purpose of Unit Testing
A unit test examines the "one unit" of the product's program code separately from the entire system and checks to see if the results are expected. The size of the "one unit" to be tested is based on the size of a coherent set of functions and the actual change (varies) between a category and a package (package). The aim is to test the bugs (bugs) in the program code before consolidating the program code into the rest of the system. Junit, and so on, supports composing unit tests in Java program code.
The reason to isolate worms before integration in other parts of the system is because it is easier to find bugs (i.e. faster and cheaper) and easier to fix problems (and to show that the solution is feasible).
Unit tests provide some benefit before the initial consolidation of a small portion of the program code and the consolidation of the remaining changes. If someone needs to change the existing program code, in fact the unit test can still make him more confident of his final program code, that is, his change will not destroy anything. The better unit tests make people more confident-the ideal test must be updated before the new features are added.
2. Who will write unit tests and when to compose unit tests
Program code testing can be very tedious, especially when you're a programmer, particularly when it comes to testing other people's programs. But programmers like to write programs, so why not let programmers write programs that can be used as tests.
The correct implementation of unit testing can help programmers become more productive, while improving the quality of code for development programs. One thing you must understand is that unit testing should be part of the development process, and that the program code must be designed to be testable. The current trend is to compose unit tests before writing code, and focus on the interface and behavior of Java classes.
The benefits of writing the test first and then writing the code:
Technically, the designer is forced to consider the function of a class first, that is, the class is provided to the external interface, rather than getting bogged down in its details too soon. This is a kind of design principle advocated by object oriented.
Good testing is really a good document, and this class of users can often see the test code of the class to understand its functionality. In particular, if you get a program from someone else, writing tests on him is the best way to understand the function of the program. The principle of XP is make it simple, it is not very recommended to write another document, because the project in the development process is often in a change, if the document in the early, after the code changes have to sync the document, a lot of work, and because the project time is often not complete or inconsistent with the code, and so, It's better not to write. And if you write a document at the end of a project, developers tend to forget all the considerations of writing code at the time, and with the pressure of the next project, managers are reluctant to write documents for old projects. Problems that cause maintenance later
No one can guarantee that demand does not change, and previous projects have often had a headache for changes in demand, fearing that the changes would lead to mistakes elsewhere. To do this, in addition to the design of a good structure to split the project (loosely coupled), but if you have a test, and have established a good test framework, for the change in requirements, the changes in the code, as long as the test code to rerun, if the test passed, it will ensure the success of the modification, if the test error, will immediately find the wrong where. Modify the appropriate section and run the test until the test is fully passed.
There are often contradictions between development and testing in software companies: as development and testing are divided into two departments, the cost and time of communication are more than one layer, and communication often leads to errors. And very easy to form a vicious circle: developers in order to catch the task, write rotten code, throw it to the tester, and then write other tasks, the test of course is failed, and the code back to rewrite, testing has become a very headache. The root of this cycle is that responsibility is not clear, according to the XP rules: The person writing this code must write tests for their code, and only if the test passes, the task is completed (the tests here include all the tests, and if the test is found to cause another group to fail because of your program), It is your responsibility to notify the person concerned of the modification until the integration test is passed, so that such problems can be avoided.
In short, if a programmer wants to write a piece of code:
Write the test with JUnit first and then write the code;
Write the code, run the test, and if the test fails,
Modify the code and run the test until the test succeeds.
If you later modify the program, optimize (refactoring), just run the test code again. If all the tests are successful, the code modification is complete.
3. Combination of unit Testing and Java team development
Team development under Java, typically using CVS (version control) + ANT (Project management) + JUnit (unit test, Integration test) mode:
Every morning at work, each developer gets a working copy of the entire project from CVS server.
Get your own task and use JUnit to write the test code for today's task.
Then write the code for today's task and run the test (unit test) until the test passes.
Task completed one or two hours before work, each developer submits the task to the CVS server.
The supervisor then runs the automated test (integration test) for the entire project, and the test fails, and the relevant person is modified until all the tests pass. Work...
4. What is needed in the test control tool?
No matter who writes unit tests or when they write unit tests, our focus should be on examining the program code, primarily on the risk of generating the error. If the design file contains the use plot of the object being tested, it can be a good test source. In any case, the plots are not very clear, because they are actually written in the design perspective-so the appropriate test should have an equivalent plot, in other words, the test design should contain as much of the action or process as possible when the user actually uses the program.
Another good source of test cases is the problem found in the product program code after integration, and the maintenance problem is often worth encapsulating as a test case.
5. Why use tools such as Junit?
The previous discussion explains why we need test control tools, but why do we use Junit tools?
First of all, they are completely free.
2nd, easy to use.
The JUnit test still allows you to write more quickly when you raise the quality of your program's code l
That doesn't sound very intuitive, but that's the truth. When you use JUnit to write tests, you will spend less time removing bugs and more confidence in the changes in your program code. This confidence makes you more active in reorganizing the code and adding new features. Without testing, you will become less confident about reorganizing and adding new features because you don't know what will destroy the outcome of the output. With a comprehensive test series, you can quickly execute multiple tests after changing the program code and feel confident that your changes are not damaging anything. If you find bugs when you run a test, the original code is still clearly in your head, so it's easy to find bugs. The tests written in JUnit help you write programs at a great (extreme) pace and quickly identify weaknesses.
JUnit is very simple l
Writing tests should be simple-that's the point. If the writing test is too complex or time-consuming, the programmer cannot be asked to write the test. With JUnit you can quickly write tests and test your program code and gradually increase the test as the program code grows. As long as you write a few tests, you want to perform tests quickly and frequently without interrupting the design and development process. Using JUnit to execute tests is as easy as compiling your program code. In fact, you should perform the test at compile time as well. Compilation is the syntax of the instrumented program code and the test is to check the integrity of the program code (integrity).
The JUnit test examines its results and provides immediate feedback. L
If you're using a manual comparison to test the expectations and the actual results then testing is not very fun, and let you slow down. JUnit tests can automatically execute and check their own results. When you perform a test, you get simple and immediate feedback, such as passing or failing. And no longer need to manually check the results of the report.
JUnit tests can synthesize a hierarchy of Test series. L
JUnit can organize tests into a series of tests that can contain other tests or test lines. The compositing behavior of JUnit tests allows you to combine multiple tests and automatic regression (regression) to test the entire Test series from beginning to end. You can also perform tests at any level in the hierarchy of the Test series.
Writing JUnit tests is not a lot of money. L
Using the Junit test framework, you can write tests cheaply and enjoy the confidence provided by the test framework. Writing a test is as easy as writing a method; testing is testing the program code to test and defining the desired results. This test framework provides the background for automating the tests, and this background is part of the other test set. In testing a small amount of investment will continue to allow you to recover from time and quality.
JUnit testing improves the stability of your software. L
The less tests you write, the more unstable your program code becomes. Testing makes the software stable and builds confidence gradually because any change does not ripple through the software. The test can form the complete structure of the software's cementation.
JUnit testing is a developer test. L
JUnit testing is a highly regional (localized) test that improves developer productivity and program code quality. Unlike functional testing (function test) depending on the system as a black box to confirm the overall performance of the software as a whole, unit testing is a building block based on the internal and external test system. Developers write and have JUnit tests. Whenever a development iteration (iteration) is completed, the test package becomes part of the delivery software that provides a way to communicate, "This is the software I delivered and it was tested." 」
JUnit tests are written in Java. L
Use Java test Java software to form a seamless (seamless) boundary between test and program code. The test becomes the extension of the whole software under the control of the test and the program code can be restructured. The Java compiler's unit test static syntax check can help test the program and confirm compliance with the software interface conventions.
A test program code cannot be executed separately, it needs to be part of the execution environment. At the same time, it requires automated unit testing--such as performing all tests periodically in the system to prove that nothing is compromised. Because unit tests need to conform to specific guidelines: a successful test should not be a manual check (that would be the everlasting), a failure to pass the test should produce the file for diagnostic modification. And Junit can provide us with these conveniences. 。 So all the test developers need to write is the test code itself. Compared with Optimizeit, Jtest's expensive and super troublesome tool, its benefits starkly expose anti-liberal visible.