Test Drive Development Series Part 1: Overview Test_Driven Development Series Part i: Overviewby Wellie Chao
December 2003
I. Introduction, you may have heard of this new name: Test-Driven Development, which is very popular in a wide range of programmers, programmers in various magazines and networks. What is it? The development of test drivers is a method theory that emphasizes the test as a major part of the development process. If you care about the quality of the program, you should test before deployment. Almost everyone uses some way to test, so you may ask: Is the test not already a part of the development process? The development of test drivers should make tests into the main part of the development process.
Second, the early software development of manual testing, many people's test methods are running procedures, specifying input by manual operation and then observing output. There is still a lot of software development to continue this way. It has a key advantage: it is very easy to learn and understand. If you have a keyboard and a mouse, you can test any desktop app. If you have a web browser, you can also test web applications. This will not talk about what tips, you can think that all developers can do it. The application you see and the end user see is exactly the same, which is also a good idea, but it is not true because other test methods can be done. The shortcomings of manual testing are too much:
Manual testing needs to be repeated. Every modification, whether adding new features, changing the active behavior, or modifying the bug, you must retest the affected part, to ensure that the code you add, will not cause damage. Manual tests may cause errors. Human is not suitable for repetitive work, especially if this work is still annoying. Humans often ignore detail, which will cause the code to be destroyed. What is more likely to be: Modify this place, may affect the behavior of other code, although their relationship is not very obvious. Therefore, even if you have a very serious and responsible test, it is only limited to some parts that may affect, you can also miss some bugs or destroyed features in it elsewhere, not because you are not careful, and Because software development is a comprehensive job, the various parts of the software often have associations. In the current software project, no one can learn more about a certain code and dependence. Handmade tests cannot be individually tested for non-visual components. If you only test what you can see, then you have not tested you can't see it. This looks a very simple proposition, but it's significant. Software is complex, in order to locate and resolve errors or corrupted code, a large amount of different BUG needs to analyze the behavior of each component via "peeling" test. This is especially true for server-side software. Almost all important code in the server-side program, such as web-based programs. Indicates that layer tests can only be indirectly test business logic, which may ignore certain details. You certainly want the logical layer and representation to work well, but the logical layer is working properly based on the basis of the application. If your test is hand-made, others can't judge whether your program function is correct. Other people (such as other developers or even end users) can only accept your commitment: you have tested, all aspects meet demand. In addition to your written or verbal statement to ensure that you have tested all visual inspections, others can't verify the function correct, unless they have worked hard, this work may not be suitable for them, because They are not familiar with the boundary conditions and logic of the program.
Third, Automated Testing automatic test solves the shortcomings of manual testing. Therefore, to answer "In addition to those things that have been doing in software development, what is the development of test drivers mean?" This problem, the development of test driver introduces automated testing throughout the development process, and continuously improve these tests to accommodate Extension of program code. Pay attention to this middle of the two points, first, test is automatically indicating that it can not only be repeated, but also convenient to transplant, repeat that you can test the same code over and over again, and get each time The same result; convenient transplantation means that others can use your test, to verify that your program can pass these tests. The second point requiring the improvement of the test contains the improvement of the program itself, the test is behind the code, because this test cannot really verify the program function correctly, so the test code needs to keep synchronization with the application itself. Synchronize go ahead.
Software automatic test has two main methods. The first is the reusable Recorded Macros. Winrunner, etc. of Mercury Interactive (http://www.mercuryinteractive.com/products/winrunner) is used. Although it is easy to establish, the macro is very unstable and needs to be revised often because they usually depend on the physical location of the button and the component, not the structure position in PARSED DOCUMENT. For developers, the test framework does not have incorrect error messages, or require a lot of work to keep and code synchronization, are very painful things,
The second main method for performing the automatic test of Web Application is to program the API. This way you have a test framework, the software library can check if the conditions are met, the number and type of the error is reported, and you can call this framework in the test code. Your test code is a set of standard Java classes inherited from the test framework, which initializes objects from the application code, calling methods to verify that given inputs will result in the expected results. The programming API scheme includes JUnit, HttpUnit, various unit tests and tools for the black box Web test. This scheme is very flexible, in most cases it greatly reduces the maintenance time of test code, and makes complex function test in the application possible, especially server-side applications. This test can alternately call Programmatic Testing, API-Driven Testing, or Programmatic API-Driven Testing.
Compared with the Recorded Macros mode, the first weakness of the API-based automatic test method is that it needs longer to create time. It is difficult to reduce setting time when your problem is when the mouse moves and clicks. The second question is that most customers do not write test programs. The customer understands the business process, not the technology, the customer may think that the mouse and click the mouse is much easier, this is very important, if you want customers to participate in the development process, customers participate is the drum blower of extreme programming Recommended method.
Although this, the API-based approach has superiority in many respects, which can be used in most applications, because the application is very large if the application changes over time, so spending time on the test program maintenance than the creation time of the test program The proportion is larger. And the Recorded Macro method has a fatal restriction: You can only create test only after the application code is written. If your development habits are not tested before the program is completed, it is very good. Otherwise, if you insist on testing the habit of testing, just as the author is recommended, that very unfortunately Recorded Macros is not suitable for you, because before recording the macro, you must have a running application.
A good solution may have both Recorded Macros tests, and API-based programming tests. Test by mouse dragging You can let the end users participate in the test to ensure that your program meets business needs. The program components can be ensured in the expected case by the programming test. Use the programming test, you have two options: Function Test and Unit Test. Functional test is also called a black box test, refers to testing at a higher level without knowing (or ignoring) internal implementation. Function Test is used to verify that the program completes business needs, and it simulates interacting with the program with the final user. End users may be using web-based applications, may also use the developers of your class library through the API you provide. If you must be entangled, functional testing and black box testing still have some difference, because technical function testing can be performed in the container (if you want to measure a web program), most of the most functional tests is Don't know if you do it in the black box. In contrast, the unit test includes the verification of the underlying code, in order to ensure that the internal components are not problematic, the internal structure of the program must be understood. You also need to know the implementation of those classes and methods. If the program is a software library that is used by the developer, your unit test includes all important classes and methods, even in content that is not listed to the user's API document. Functional testing and program interaction is to enter the program visible Forms by clicking on the button and the information entry. The interaction of the unit test and the program is accessed through the Java method call. The four defects mentioned earlier tests are given a good solution:
Exclude repetition. With automated test you can handle this job to your computer, which will operate strictly according to the process you test. Reduce errors. The computer performs repeated operations each time. Moreover, because the test is Cumulative, and it is easy to call, even if some code modifications are destroyed in a direct impact, you can find this error because you have written for those (partially destroyed part) code. Test will tell you. Automatic test Cumulative is a very useful feature and is also an important advantage for relative manual testing. Checking the other parts of the program with manual testing is unrealistic. Allow components to independent testing. Automatic testing, at least in the API-based programming method, you can make your testing the unacceptable part of the program, for example, you think is the business logic of the program core. Programming Test calls your code in other programs (test code). The particle size is grasped by yourself. If you do not consider any internal implementation of the program, you can simulate a web browser or use the mouse to operate the desktop, black box or function test. You can also call Cult Public API because you don't consider the implementation of the API, which can also be counted as a black box or functional test. You can also call the internal method of hiding classes or public categories to verify that they work as you think because it is independent approach and classes, and you will know the internal implementation details such as algorithms, this is the unit test. What level of test do you have to do? Let the end user to verify the functionality of the software. Its role not only is the BUG that prevents user data, but also helps discover your software in a new environment that may occur in the new environment. The new environment includes different operating systems, new hardware platforms, different network configurations, or a wide variety of differences. Automatic testing can transfer your tests to other platforms, make sure your program can run correctly anywhere.
Fourth, several tools under tools are very useful for automated tests:
Junit. JUnit is the nasal ancestors of the unit test. Other tools are often created on a JUnit, because Junit provides two functions that must be used in unit testing and functional testing: assertion checks and results reports. JUnit. Httpunit can be found at www.junit.org. HTTPUNIT is a test framework built on JUnit, which supports black box testing and in-container testing for web applications. It is a functional test tool that you can use it to verify that the software meets business needs and meets the expected behavior at the visual level. Interestingly, httpunit's basic code actually doesn't matter with test. The purpose of the HTTPUNIT library is to enhance HTTP's access to web applications. It supports features, request submission, response analysis (HTML parsing), and some of the web spider toolkit needed. Features. HttpUnit also has a class servletUnit that supports the container. Based on the assertion function and result reporting feature provided by Junit, HttpUnit has become a very useful tool for testing web applications. HttpUnit, jwebunit can be found at www.httpunit.org. Jwebunit is an auxiliary kit created on HTTPUnit, which reduces the code you write by the test web program. Simply put, you can use it as a macro sequence of httpunit, provide a shortcut to the HTTPUnit code segment, simplify most of the Web program test. HttpUnit offers a relatively underlying interface to let you customize many things yourself. You may think that jwebunit is useful, or it may not, if you can solve all your questions in httpunit, jwebunit can also. It may bring more code, but you have better control. You can find jwebunit at http://jwebunit.sourceforge.net/. StrutstestCase. StrutstestCase is the test framework created on the JUnit application for testing the Struts application. Struts is a model that uses Java development web applications - Trial-Controller (MVC) platform, which simplifies data, representation, and logical separation of easy maintenance component code development. Struts makes the function testing and unit test of the web program container (in-container) because they clip between the servlet container and your programs. This means that this test framework is to know Struts, which can process Struts's container tests. Since there is no need to know the internal implementation of the web program, the black box test of HttpUnit is still working very well. However, you can't use HTTPUnit to test the Struts application to the container test because HttpUnit is independently located between your programs and servlet containers. Strutstestcase is designed for containers designed for Struts programs. StrutstestCase can be obtained at http://strutstestcase.sourceforge.net/.
5. Conclusion (Conclusion) If you agree to test is important, not just need, then you will start automating your test, or continue to use automated test. If you agree that the automatic test is superior to manual test, it is reasonable to develop automatic testing while developing code. Maintaining test code is just a little burden, but it doesn't have to worry about whether the program meets the requirements of test code. The two principles of automatic testing code modified by automatic testing and program code are used, and you are using the development of test drivers. The reliability and quality of the program will be improved, your customers, whether the outside of retail customers, or other sectors, may thank you, or less because the software is unstable to bother you, or both are all. Finally, the test software writes the test code is much more interesting. Now prepare the next paper for reading the development of test drivers. This paper titled "Development of Business Test" ("Test-Driven Development for the Business Tier") will explore details of server-side component tests, including EJBs and ordinary Java classes. Author Wellie Chao has been interested in software development since 1984 and has become an occupational programmer in 1994. He led several software projects to build enterprises. They had a deep accomplishment in Java and Perl. He published several Java books, of which "Core Java Tools" (Prentice Hall) tells the use of Ant, CVS and JUnit and other open source Java tools for extreme programming and test-driven development. He published in IBMDeveloperWorks, DEVX, THESERVERSIDE, and other places cover the topic of Java programmers in the development of enterprise software. He is honored to graduate from Harvard University, where he studies economics and computers, and he is now in New York.
