Drinking with junit
Author: Le dawn [airwalker@263.net] (welcome to reprint this article freely but please indicate the author and source)
Safe and scalability and readability and readability have entered the object, it supports the entire project as a large number.
1. Purpose u understands the purpose and method of system testing and unit testing
u Examine the client-layer application of the JUnit test framework; and architecture a system case to be tested. u exam analysis of the principle of framework architecture of JUnit.
2. Testing
2.1 Software Entropy Concept: A program starts from the design of a very good state, as the new features continue to join, the program gradually lost the original structure, and eventually become a mess. (In fact, the "very good state" is added?) 2.2 Tests: Simple and energetic, write high quality software and solve the problem of software entropy.
2.3 Classification of tests: white box test, black box test; or, unit test, integrated test, function test, etc. have a variety of classification methods. White Box Test -> Refers to how to test the software (how) complete function test and do what kind of function (What) is tested under conditions. (Generally completed by developers)
The unit test should belong to the white box test. Blackbox Test -> Tests made under conditions that do (What) of the software that is tested. (Generally completed by testers)
Unit Test -> Objective To verify that one or several categories are working and manifesting as designed. Integrated Test -> Verify that all classes can cooperate to cooperate to complete specific tasks. (Complex signal and event communication with state machine classified operation test) <<< junit is applied to unit testing >>>> 2.4 test as a continuous process, it runs through the entire process of development, unit test Suitable for the development process of Iteeraton and Incremental.
The easiest saying: The test is to compare whether the expected result is consistent with the actual execution results.
3.architecture of Junit 3.1 Goal of Junit U Create a universal test framework to encapsulate the test code into the object, so that developers are willing to synchronize and configure their unit tests. u Let the test code have presupported, making (in the past, personalized) test code, standardize, can be browsed and maintained for many people. u Strip the test code from the system code, and the two can develop synchronously. 3.2 JUnit Frame Members Logic Analysis 1. The object (class, multiple classes, subsystems) (Object be ties) 2. Method for testing the test target and the process set, can be referred to as a test container. (TestCase) 3. Collection of testing services can accommodate multiple test containers (TestCase), referred to as test transaction bags. 4. Description and record of test results. 5. Description of each test method and the description of the expected inconsistent condition, called its test failure element. (TestFail) 6. Error abnormality in JUnit Framework. (AssertionFaileDerror) 3.3 JUnit Framework function and principle Description (junit.framework. *) U Test interface and TestCase, TestSuite form a Composite structure, Run (TestResult) is Composite Methode. Test is Component, the derived testcase is Leaf, which is the execution element of the test; TestSuite is Composite, which can accommodate the TestCase or testsuite to form a test package.
U TestCase can be used as a run entity of the test unit in the frame. Users can derive custom test procedures and methods (units), using Command Pattern and Composite Pattern to form a combined assembleable test batch. The TestCase itself operates to operate as Run (TestResult), which perform setup (), RUNTEST (), and Teardown () to schema testing process. Template MothoD Pattern User No need to understand the process details of the execution of the framework, but only need to redefine the test pre-processing, test unit processes, and test three template mothod to test the test correctly.
U User layers can integrate overload Runtest () formation feature test classes through Java's anonymous internal classes, while JUnit 3.0 is enabled by using Java's class attribute to dynamically generate these characteristic test units. Class, and users only need TestXxxx () in TestCase to use Return New TestSuite (MyTestCase.class) in Suite; then the testSuite contains all Testxxx Tests Test Procedure Tests.
The U assert class contains Assertequal (.), AssertSame (.), Static Tools Methods, STATIC Tools Methods, for the user's type as possible, the JUnit framework will be Assert Testcase's superclass, TestCase simultaneously inherits Assert's implementation with the Test interface (Class Adepter Pattern). Users can call these assertxxxx (.) And other static tool methods directly in TestCase. U TestResult describes the test results of the entire test execution process, the JUnit framework transmits it as a parameter to the TEST RUN (.), which contains all TestCase test results when the test task is executed. The default TestResult of the framework is TextTestResult, and the user can customize its TestResult's return format, such as HTMLTestResult.
TestFailure describes the error message during the test process, and the testResult contains TestFail, which is generated during the test process, by vector, which is based on the test results parameter. 4. CLIIENT LAYER OF JUNIT
Import junit.framework. *; User passes the TestCase from the defined feature TEST case, in TestCase, can include the object to be tested to be tested, while defining a number of Testxxxx () do Test Method. Override setup () to do system state pretreatment before each test, cleaning in Teardown ().
Arranging test processes There are two common methods: 1. Create a built-in runtxxxx () by creating an internal class, filling TestXxxx () 2. This is dynamically created by Class as TestSuite constructor. (All of these TestXxx () are respectively a new feature TestCase test master method [Runtest {Testxxxx ();}])
Note that each test should be independent of each other, and the test object should not have a context. (This is due to TestSuite to accommodate Test's disorder)
5. Test Zerg-Command-System with Junit
As a JUnit test case, I structure a test case.
As a unit test framework, the developer should clearly create what test, how to test, what parts and methods of the test system, or the integration of the test system.
The system describes an alien race Zerg's Planet Combat Command System.
The zcommand system is a Command & Composite architecture, ZcommandGroup accommodates several commands (can be considered), ZConcreteCommand (zcfire / zcloadammo / zcAction) describes three specific command categories (including specific characteristic parameters)
Zcommand's Execute is a Composite Method that can handle batch execution of the combination command.
While architecturalization, use the JUnit framework to test the nature of this combination. To investigate the command system, the algorithm complex area is manifested in the process of combining integration, as well as the traversal process of the combination execution.
Public class testcommandmodmodel extends Testcase {}
1. TestCommandGroupCount () Tests the number of subcommands included in a combination command.
2. TestCommandstring () Test the traversal return process executed by the combination command. 3. TestCommandGroupUpdate () Tests the correctness of combined operations of add, remove, clear.
(See Junitzerg.Test.TestCommandmodel.java for details)
ZfighterMachine describes a combat command terminal. ZergCommandCentre describes the Zerg Combat Command Treatment Center, ZfighterMachine passes the Zcommand (Component) generated by the combat staff to ZcommandCentre (Remote Object) to process the instruction and wait for a result.
ZcommandCentre maintains a system's working state, and different combat instructions have different ways of processing in different system working conditions, which forms a complex logic zone (Complex Logic Zone).
The signal incoming and result feedback of the logical zone should be based on the content that the unit test should be implemented. The price is constructed with TestMachine to test the working status of ZfighterMachine with ZergCommandCentre.
Public Class TestMachine Extends TestCase {} 1. TestsImpleCommand () Test Simple instruction elements perform results in different system states. 2. TESTEXTREMECONDITION () Tests the work of ZergcommandCentre in extreme environments (indifferent energy, lack of ammunition, communication interference). 3. TestallCondition () Tests all kinds of Command's execution results and working conditions under all Condition. (Note: See Junitzerg.Test.TestMachine.java, Testall Batch Execute All Tests) 6. Summary & Conclusion
1. Design a test that should fail. 2. Do not initialize FixTures with TestCase, with Setup / Teardown. 3. Avoid writing TestCase with side effects. 4. Ensure that the test has nothing to do with time, Mo Yai uses expired data for testing.
5. Use the assertxxx / fail method provided by JUnit as much as possible to unifold the test code.
6. If the written software is facing the international market, it is necessary to consider international factors when preparing the test.
7. Inadvertently discovered that the author of JUnit includes Erich Gamma.
7. EXTENSION1. The key to test is to inspect the complex area of the system and the unstable area to extract it to test. 2. Manage the test module and the system itself module to develop synchronously.
3. JUnit is only an application framework for a unit test, and it will be in the framework of the integrated test. 4. Examination summary development and testing work mode to accelerate the operational efficiency of engineering development.
Yue Yucuo 2002-2-26
