The test cannot prove that the error does not exist, only the error can be proved. Test everything as much as possible.
How to drive the development process
The test driver development originated in the promotion of test priorities in XP law. Test priority practice pay attention to unit testing, emphasizing programmers, in addition to writing code, should also write unit test code. In the order of development, it has changed the process of writing code in the past, and then writing tests, and using first-write test, then write code to meet the test method. This approach can play a very good effect in practice, making the testing not only a simple test, but a part of the design. Why do you say this?
Everyone will work before writing programs. Some people may have a formal, draw model, write a document. Some people's design only exist in the mind. And whether it is fine or rough, you have developed a standard for subsequent encoding activities. The clear level of this standard is related to the meticulousness of your design. But it should be recognized that this standard is not refinered enough. Because your design is impossible to fine into the level of the code level. It will produce some problems, for example, in the process of writing code, you may also find the original design problem, thereby changing the writing ideas of the code. This will result in difficult results, and the progress is difficult to measure.
Since design-oriented standards are not clear enough, it is not specific. What kind of standard is it right? Can only be code. Because the code is the most clear, the most specific. So the essence of test priority is actually target management. The writing test code is actually developing a small goal. This small goal is very clear, it specifies the class, method you need to design. And the method needs to meet the results. After these goals have been completed, you start writing code to achieve this goal. The target of the test is smaller than the design of the design, but it is more economical. The reason is four:
The fine-grained design requires a lot of cost, although the CASE tool provides the function of automatic code, but the result is often difficult to satisfactorily. So, if you want to do and test the same particle size, cost is not well, if the particle size is not fine enough, the meaning of the guidance is not enough. Reduce the workload of the test. No matter whether it is designed, the test work is inevitable, advanced unit testing, can reduce subsequent test workload. During test priority, the design has a large particle size. Since the test can achieve a part of the design work. In this way, some workload can be saved. For example, you no longer need to detail the class to each method. The cost spent on the test code will be rewarded on the regression test. The biggest advantage of automated test is to avoid regression of code. The two-phase weighing, the cost of writing test is not high.
You may say that I don't make such a fine design, nor don't write test code in advance. Is this cost not the lowest? Please note that our premise is to discuss high quality software design. It is indeed so much in some projects that are small or very developers. But for high-quality projects, this development idea in chaotic state is not advisable.
Test is preferred to develop a fine-grained target management method in software development, driving software development through clear goals.
In the industry, it is very common to use testing as an evaluation software standard. For example, Sun has specifically designed test software to test each product that implements J2EE specifications. The most advantageous use of testing as a specification is clear, specifically.
Use the test code to establish a target, write code to complete the test target, and then make the next goal, so loop constitutes a workflow for test-driven development. In the next space, we have begun to discuss some problems that need to be careful in the test drive development.
Test must be automated
And automated testing is a manual test. Manual test has the advantage of automated testing. The most obvious is simple. Any developer can perform manual testing. Even the user is easy to master the manual test, they enter the data, and observe the reactions of the software (output), and determine whether the behavior is correct. Most manual tests are inspected for input and output. It is an end-to-end process, which can explain the problem. But the problem with manual testing is much more than the benefits it. Manual testing may introduce an error, and the human input error is easy, especially in the case of large data; a large number of repetitive manual tests may be higher, if the software needs to repeat the manual test, this cost is also required. It will be higher; the coverage of manual testing is not wide, only the input and output of the system can be tested; there is no way to isolate the components, resulting in the cost of finding problems and solving problems.
Based on the above discussion, we should see that the test should be automated. Although the cost of testing automation is high, from the entire development process, the value generated by the automation test far exceeds its cost.
The range of automation tests
So, what are you needed to be included in the range of automation tests? For example, for a typical layered application, there is a database layer, a database access layer, a business logic layer, an interface control layer, and an interface layer. These levels of testing features are different, what should be automated? The most ideal situation is all. Testing everything may be the basic principle of testing, letting all tests become automated to test the guidelines for testing drive development.
It should be acknowledged that the establishment of an automated test requires cost, and some automated test costs are low, and some are higher. For example, the automation test of the business method is relatively easy, and the test of the business method associated with the database is cumbersome, because you need to handle more situations. The automation test of the interface is more difficult because the interface involves a large number of human-machine interactions, manual testing is very simple, but automated test is quite difficult.
So, let's take a look, the high test of this cost is required to automate it. We take the resident web interface to see examples of human machine interaction interfaces.
First, according to the principles of the hierarchical, the interface should not have business logic. The responsible thing to the interface layer is to collect the user's actions, and delegate the user's action request to the back-end business layer, and respond to the action. Therefore, the logic related to the business has been stripped to the business layer. Its automation test belongs to the business layer. At the same time, we have also found that under the promotion of the test, the structure of the software becomes more reasonable.
Second, although the business logic migrates a large number of interface layers, there is still a state in the interface layer, and also control logic. These factors are related to the performance of the interface control. Since there is logic, you need to test. According to the MVC's idea, the interface layer contains models, views, and controllers. The model is a package of business layer data, in J2EE applications, may be ordinary JavaBean, or offline data package, or simple data collection. The view is responsible for the performance model, and the responsibility of the controller is more responsible for processing and inspecting the request parameters, responsible for calling the business object and transmits the data contained in the request, responsible for creating a model, responsible for generating a view and passing the model to it.
Therefore, in a real MVC interface design, the test focus is in the controller. The test of the model is very easy, most models only contain data, so there is no test. A perfect view, it should not contain any logic, just just a model in some way. A design excellent view can be easily replaced without any impact. For example, a JSP view can be replaced with an XSLT view. Therefore, the structure of the structure is also not required (but inspections for page elements is necessary). Note that the discussion here also shows that the test driver design has developed in a reasonable direction. Most of the controllers are servlet technology, servlet technology is a typical container application, which makes JUnit not to be used. Cactus (http://jakarta.apache.org/cactus/index.html) can solve this problem, it has expanded JUnit, providing a large number of preset features, simplifying the use of Request, Response, Session, Cactus With Redirector Proxy, a test client and test server model have been established to implement a test based on the container. The following figure is the structure of the typical servlet:
Detailed working mechanism of CACTUS can refer to here (http://jakarta.apache.org/cactus/how_it_works.html).
In addition to constructing a container for testing, another way, fundamentally changes the test method of the controller, that is, do not implement the controller over the servlet technology. The benefits of doing this are that tests do not depend on the container. A typical web layer of SpringFramework (http://www.springframework.org/) is designed.
Regardless of how the method is used, it has shown that the software industry has begun to pay full attention on the automation test of the interface, and a lot of solutions have been proposed. The purpose of this is nothing more than two points: First, the software quality is improved through automated testing, and the second is to promote the design optimization through the attention of the test.
Finally, from the development culture. The requirements for interface automation tests mean that developers need to fully communicate with users, plot to meet the needs of the page, this is actually the application of prototype methods, which is advantageous for the development process. In addition, developers need to carefully think about page design, guarantee the variability and scalability of page design, otherwise you will find test code very unstable, resulting in some unnecessary trouble. This culture will promote the development of the design.
So we see that the cost of automated testing can be reduced by a reasonable design and introduction tool in a high cost of automated testing. Moreover, in the above discussion, we also found that the cost of automated test is high, which is often caused by improper design. In the interface mixed logic, the change is constantly incurred, but not only the code needs to be modified, the test code also needs to be modified, but the design is just a high cost of the culprit. It is also for this reason that the test can drive the design optimization.
Classification of tests
unit test
Unit test is a typical black box test for code logic. In the test drive method, it is not highly emphasized that the white box test (most of the white box test is performed by the review). The benefits of doing this are to pay attention to the implementation of attention, which is an effective way to analyze complex software. This will also be discussed in subsequent articles.
Unit testing is the duties of the developer. In general, the code is best to be responsible for different people to avoid blind spots to improve the effectiveness of the test. However, the particle size of the unit test is small, and if the division of labor is performed, the cost of communication will be quite high. In addition, test priority practice is used, and the test is appropriately trained, and it can also effectively reduce the blind spot range of individual people. Unit tests can be added to the group day building, or may not be added. If you don't join, there is a need to have a mechanism to manage unit test activities.
Integration Testing
The particle size and test of the integrated test is larger than the unit test. We take the database test to do an example. Now you need to test a business object, it needs to use a persistence mechanism. In unit testing, we will not involve the database and test the business object separately (using MO technology, discussed below); however, in integrated testing, we need to incorporate the data consistency of the database, so testing includes database data Establish, test business methods to restore the database.
The integrated test should be an important part of the day building, the test standard in the day construct standard. It is best to give an integrated test to the QA department. The power of the QA department can be placed in use or writing some tools (CACTUS is a typical integrated test tool), establishing standard test data, arranges test plans, etc.
Accept test
Sometimes it is difficult to distinguish between integrated tests and acceptance tests. The focus of accepting tests is the user. The user observes the output of the system by using the data input system. Therefore, understand the needs of users and convert users to accept testing is the most critical work in the test. The final link of the test process is to determine whether the software meets the demand for users. No exception. Accept tests should also be automated. For example, httpunit is a tool for automated acceptance tests. In addition, many of the automated scripting tests provided by many professional test tools are also in this category.
Test propulsion design
In the discussion of interface tests, we have realized that the test can drive design. Here we intend to discuss the relationship between tests and designs in conjunction with specific technologies.
For interface design
The test drive method uses a black box test, in order to ensure the stability of the test, the stability of the test code interface is very important. Otherwise, the cost of change will rise sharply. Therefore, the automation test will require your design depending on the interface, not a specific class. This design is currently recognized as a good design idea.
MO technology
Here will not be introduced here in the Mo (Mock Object, Pseudo-Object) technology, which already has this discussion article in the DW area. The focus here is to discuss how to use MO technology correctly. People who have used MO have such doubts, MO technology is too much trouble, writing a large number of pseudo-objects is just to cooperate with test objects, and there is no big small matter.
In fact, the biggest benefits of MO technology are not just the test itself, MO technology will drive design towards the interface and can be sabted. Because MO technology needs to switch between pseudo-objects and actual objects, this ability is very important for software architectures, which fully demonstrates architectural scalability and resistance.
Of course, in practice, MO technology does need to increase a lot of code. There are some tools to simplify your work, such as some tools such as Easymock.
Test coverage
Unit tests drive code quality;
Clover Drives Unit Test Quality.
The above two sentences are the advertisements of clover (http://www.thecortex.net/clover/index.html), which deducts the meaning of advertisements, this sentence is still very reasonable. Our introduction shows that there is no way to test the error does not exist. Therefore, it is necessary to analyze the test, and the test coverage is the most important indicator. Test coverage analysis has two methods: code coverage and branch condition coverage. Covering the testing of the test is an important method of software metrics. It is also a component of the test, and a lot of open source projects have incorporated it into the day construct.
Cost of test
Although we have discussed a lot of exciting ideas and technologies. You may have a bloody intention to implement a test drive method in the organization. But I have to pour you cold water. The introduction of the test drive method is not a simple process, and it is even quite difficult to do for some companies. This is because the following reasons:
The estimation method of workload needs to be changed. In the test drive method, a developer needs to write a test code, which will need to have a test code, which will increase the workload, in order to automate testing, the improvement of the design will take a certain amount of time. Therefore, there is no meaning of the developer to learn to test the driver method, the key is to have enough time to leave for them.
project progress. Due to the rise of the workload and the use of new knowledge, the project progress will drop rapidly, and then with the skill of developers and the advantages of automation tests will slowly rebound, if the implementation is successful, the final project speed will exceed the implementation This is completely possible.
Personal initiative and courage. According to our experience, many organizations and developers can recognize the benefits of test drivers, but often due to the reasons for the reality environment, the implementation of the test drive method is not successive. Organizations due to the time pressure of the project, leading to the promotion of the test drive method, often a taste. Due to lack of adequate patience and time, individuals have caused their unwillingness to refactor with design, and this is precisely the premise of testing.
The application of the test drive method is not that simple, and if there is not enough courage to do if there is not enough courage. So, why we stressed the beginning of this article, the readers of this article are those who are responsible and very sensitive to quality, one of which is here.
Establish test culture
The test driver is not a simple methodology, which will not compete with any methodology. In fact, no matter what method or process in your organization, you can profit from the test drive. Because it emphasizes quality culture.
Working with tests as a core work, testing also requires reconstruction, and the required documentation.
Directory organization and packages of fixed tests. For example, a preferred tissue test is to adopt the same package name and source code, but in a completely different directory.
Make the test becomes the core step created by the day.
Test is a matter of everyone, not just QA.
Learn more about
From the JUnit's website (http://www.junit.org /), you can learn about the large amount of information in JUnit, including an introductory article, JUnit's extension.
