Unit Testing Overview

1. Why unit testing is required

The standard processes for software development include the following phases: [Requirements analysis phase], [design phase], [implementation phase], [test phase], [release]. The process by which the test phase runs or tests a system by manual or automated means to verify that it meets the required requirements or to ascertain the difference between the expected result and the actual result. Software testing can be divided into unit test, integration test, function test, System test and so on according to the engineering idea. Functional testing and system testing are generally the responsibility of testers, but unit testing and integration must be guaranteed by the developer.

1) Unit test: A small piece of code written by the developer during unit testing to verify that a small, well-defined function of the target code is correct. Typically, a unit test is used to determine the behavior of a particular condition or a particular function under a particular scenario. In one case, a functional module will often invoke other functional modules to complete a function, such as business layer business classes that may invoke multiple DAO to accomplish a task. When unit testing a function module, we want to block the dependency of the external function module so as to focus on the test of the target function module. The simulation object is the most powerful tool, which simulates the specific operation behavior according to the interface of the external module, so that the unit test can verify the correctness of the logic of this module in the case of assuming the correlation module works correctly.

2) Integration testing: Integration testing is done after the development of the function module, to verify the correctness of the matching call between the functional modules. In unit testing, it is often necessary to shield the dependencies of external modules by simulating objects, while integration testing is exactly the correct integration between modules.

3) Functional Testing: Functional testing is primarily to check whether the implemented software meets the requirements identified in the requirements specification, and whether the software function is complete or correct.

4) The system test mainly integrates with other system components in the actual operating environment for the software that has been determined.

2. Benefits of testing

1) Software quality is the simplest and most effective guarantee;

2) is the most clear and effective document of the target code;

3) can optimize the design of the target code;

4) is the protection of code refactoring;

5) is the cornerstone of regression testing and continuous integration.

3. Basic concept of Unit testing

1) Dut: SUT (System under test)

The system under test indicates the system being tested to test whether the system is operating correctly. A special case of software system testing is the testing of application software, known as the application under test (Aut,application under test). SUT also shows that the software has reached maturity, because system testing is the latter phase of integration testing in the test cycle.

2) Test alias: Double

In unit testing, using Test double reduces the dependency on the object under test, making the tests more singular. At the same time, the test case executes more quickly, runs more stably, and validates the input and output inside the SUT, allowing the test to be more thorough. However, Test double is not omnipotent, and test double cannot be overused because the actual delivery of the product is using the actual object, and over-using the test double will make testing more and more detached from the actual.

To understand the test doubles, you need to understand the concepts of dummy object, test stub,test Spy, Fake object.

A, Dummy Object: Dummy object refers to the objects that must be passed in the test, and the objects passed in do not actually have any effect, just to be able to invoke one of the objects that must be passed to the object being tested.

B, Test Stub: The testing pile is used to accept SUT internal indirect input (indirect inputs) and return a specific value to SUT. It can be understood that the test stub is a pile inside the SUT that can return specific content to the sut,test stub in accordance with our requirements the interaction is entirely within SUT, so it does not return content to the test case, nor does it validate the input inside the SUT.

C, Test Spy: The Test spy, like a spy, was placed inside the SUT and was specifically responsible for transmitting the SUT internal indirect output (indirect outputs) to the outside. It is characterized by the return of the internal indirect output to the test case, verified by the test case, the test spy is only responsible for obtaining internal intelligence, and send out information, not responsible for verifying the correctness of the information.

D, Mock Object: Mock object and test spy have a similar place, it is also placed inside the SUT, get to SUT internal indirect output (indirect outputs), different is, Mock object is also responsible for the intelligence (intelligence) to verify, The Headquarters (external test case) trusts the validation result of the mock object.

E, Fake object: Often, we confuse the Fake object with the test stub, because they have no interaction with the outside and do not validate the internal input and output. The difference is that Fake object is not concerned with indirect input (indirect inputs) or indirect output (indirect outputs) inside SUT, which is simply a substitute for an actual object and has almost the same functionality as the actual object. Ensure that the SUT is working properly. The actual object is overly dependent on the external environment, and Fake object can reduce this dependency.

3) Testing Fixture: Test Fixture

The test fixture (Fixture) is the test run program that automatically initializes and reclaims resources before testing the method (Test runner). Initialize the field and configure the environment through @before in JUNIT4, and log off through @after. This guarantees the independence and non-interference of each test, but is inefficient.

A test case can contain several test methods that @test annotations, test cases test one or more class API interface correctness, of course, when invoking the class API, you need to create this class of objects and some associated objects, this group of objects called Test fixture (Fixture), Equivalent to the "work object" of the test case.

4) test Case:

In JUnit3, the test method must be prefixed with test, and must be public void, after JUNIT4, there is no such limit, as long as each test method annotation @test annotations, 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) Testing Suite: Test suite

When multiple test cases are assembled into a single test suite through the Testsuite object, the test suite runs in batches. In particular, it is possible to add a test suite to 21 test suites, just like a basket of baskets into a large bag.

The suite mechanism is used to logically group tests and run them as a unit test. JUNIT4 in order to replace the old version of the suite test, the kit was replaced by two new annotations: @RunWith, @SuteClasses. The @runwith specifies a special runner, the Suite.class Suite runner, and passes the @suiteclasses annotation, passing in the list of classes that need to be tested as parameters.

To create a step description:

* Create an empty class as the entrance to the test suite (this empty class must use the public modifier, and there is no parameter constructor);

* @runwith, @SuiteClasses annotations are decorated with this empty class;

* Pass Suite.class as a parameter into the @runwith comment to prompt junit to designate this class as a runner;

* Make an array of the classes you want to test as @suiteclasses parameters.

6) Assertion: Assertions

Assertions (assertions) are several methods within a test framework that determine whether a statement's results are true or whether it matches the expectations.

Unit Testing Overview