This article comes from: http://www.cnblogs.com/yangyquin/p/5768522.html
1. Why do you need unit testing?
The standard process of software development includes the following stages: [requirements analysis stage], [design stage], [implementation stage], [testing stage], [release]. The testing phase is the process of running or testing a system by manual or automatic means, with the purpose of verifying that it meets specified requirements or clarifying the difference between expected and actual results. According to the idea of software engineering, software testing can be divided into unit testing, integration testing, functional testing, system testing and so on. Functional testing and system testing are generally the responsibility of testers, but unit testing and integration must be guaranteed by developers.
1) Unit testing: A small piece of code written by the developer during unit testing to check whether a small, well-defined function of the target code is correct. Typically, a unit test is used to determine the behavior of a specific function under a specific condition or in a specific scenario. In one case, a function module often calls other function modules to complete a certain function. For example, the business class of the business layer may call multiple DAOs to complete a certain task. When unit testing a functional module, we hope to shield the dependencies of external functional modules so as to focus on the testing of the target functional module. At this time, the mock object is the most powerful tool. It simulates a specific operation behavior according to the interface of the external module, so that the unit test can verify the correctness of the logic of the module under the assumption that the associated module is working correctly.
2) Integration test: The integration test is a test to verify the correctness of matching calls between functional modules after the development of functional modules is completed. In unit testing, it is often necessary to shield the dependencies of external modules through mock objects, and integration testing is precisely to verify the correctness of the integration between modules.
3) Functional testing: Functional testing mainly checks whether the implemented software meets the various requirements identified in the requirements specification, and whether the software functions are complete and correct.
4) System testing mainly integrates the software that has been determined into the actual operating environment and combines it with other system components for testing.
2. The benefits of testing
1) It is the simplest and most effective guarantee of software quality;
2) It is the clearest and most effective document for the target code;
3) The design of the target code can be optimized;
4) It is the guarantee of code refactoring;
5) is the cornerstone of regression testing and continuous integration.
3. Basic concepts of unit testing
1) System under test: SUT (System Under Test)
The system under test represents the system being tested in order to test whether the system operates correctly. A special case of software system testing is the testing of application software, called the Application Under Test (AUT). SUT also indicates that the software has reached maturity, as system testing is the last stage of integration testing in the test cycle.
2) Test Double: Test Double
When unit testing, use Test Double to reduce the dependency on the object under test and make the test more single. At the same time, the execution time of the test case is shorter, the operation is more stable, and the internal input and output of the SUT can be verified, making the test more thorough and in-depth. However, Test Double is not a panacea, and Test Double cannot be overused, because the actual delivered product uses actual objects, and overuse of Test Double will make the test more and more unrealistic.
To understand test doubles, you need to understand the concepts of Dummy Object, Test Stub, Test Spy, and Fake Object.
a. Dummy Object: Dummy Object generally refers to the objects that must be passed in during the test, and the passed-in objects do not actually have any effect, just something that must be passed in in order to be able to call the tested object.
b. Test Stub: The test stub is used to accept indirect inputs inside the SUT and return specific values to the SUT. It can be understood that the Test Stub is a pile built inside the SUT. It can return specific content to the SUT according to our requirements. The interaction of the Test Stub is completely inside the SUT. Therefore, it will not return the content to the test case, nor will it affect the SUT. Internal input is validated.
c. Test Spy: Test Spy, like a spy, is placed inside the SUT, and is specially responsible for passing the indirect outputs inside the SUT to the outside. Its characteristic is that the internal indirect output is returned to the test case, which is verified by the test case. Test Spy is only responsible for obtaining internal intelligence and sending it out, and is not responsible for verifying the correctness of the intelligence.
d. Mock Object: Mock Object is similar to Test Spy. It is also installed inside SUT to obtain indirect outputs inside SUT. The difference is that Mock Object is also responsible for verifying intelligence. The headquarters (external test case) trusts the verification result of the Mock Object.
e. Fake Object: Often, we confuse Fake Object and Test Stub, because they have no interaction with the outside, and do not verify the internal input and output. The difference is that Fake Object does not pay attention to the indirect inputs or indirect outputs inside the SUT, it is only used to replace an actual object, and has almost the same function as the actual object, ensuring that the SUT can normal work. The actual object relies too much on the external environment, and Fake Object can reduce such dependence.
3) Test fixture: Test Fixture
A test fixture is a test runner that automatically initializes and recycles resources before a test method. In Junit4, fields and configuration environments are initialized through @Before, and deregistered through @After. This can ensure the independence and non-interference between the various tests, but the efficiency is low.
A test case can contain several test methods annotated with @Test. The test case tests the correctness of one or more class API interfaces. Of course, when calling a class API, an object of this class and some associated objects need to be created in advance. The group object is called a test fixture (Fixture), which is equivalent to the "work object" of the test case.
4) Test case: Test Case
In JUnit3, test methods must be prefixed with test, and must be public void. After JUnit4, there is no such restriction. As long as each test method is marked with the @Test annotation, the method signature can be any name. You can add multiple test methods to a test case class, and the runner generates a test case instance for each method and runs it separately.
5) Test Suite: Test Suite
Multiple test cases are assembled into a test suite through the TestSuite object, and the test suite is run in batches. It should be pointed out that one test suite can be added to two test suites as a whole, just like a small basket is put into a large basket and becomes a basket.
The suite mechanism is used to logically group tests and run them as a unit test. In order to replace the old version of the suite test in Junit4, the suite is replaced by two new annotations: @RunWith, @SuteClasses. Specify a special runner, the Suite.class suite runner, through @RunWith, and pass in the list of classes to be tested as parameters through the @SuiteClasses annotation.
Instructions for creating steps:
* Create an empty class as the entry point of the test suite (this empty class must use the public modifier, and there is a no-argument constructor);
* Decorate this empty class with @RunWith, @SuiteClasses annotations;
* Pass Suite.class as a parameter to the @RunWith annotation to prompt Junit to specify this class as a runner;
* Form an array of classes to be tested as a parameter of @SuiteClasses.
6) Assertions: Assertions
Assertions are a number of methods in the test framework that are used to determine whether the result of a statement is true or whether it is in line with expectations.