Some summary of UT

This article is an individual's thoughts and summary of UT, please refer to the official information for reference.

Reprint Please specify source: http://www.cnblogs.com/sizzle/p/4476392.html

Test ideas

The UT test code is written, usually to achieve the following purposes:

• Confirm the correctness of some modules before the program can run.
• Implement automated testing to reduce labor costs.
• Increase the testing means to reduce the probability of the bug to downstream.
• The effect of changing the code explicitly.

But in the actual development process, UT made it difficult to achieve the above objectives, but will have some side effects:

• The UT code is difficult to write resulting in increased costs.
• The number of bugs detected with UT is low, and even the bugs detected at the beginning are invalid bugs introduced by UT writing errors.

The problem occurs because developers do not consider testability when designing and coding, which causes UT to be prone to more harm than beneficial.
The ability to fully consider testability in design and coding requires extensive testing experience and is difficult to achieve, resulting in a "test-driven development" (Test driven development, abbreviated as TDD).
The process of TDD testing is simple and can be summed up in the following steps:

1. Write the test code according to the requirements and interface specifications to verify that the functionality code that is written next meets the desired point of demand (the test result is ng at this point).
2. Write the function code.
3. Confirm the test results, if NG needs to modify the function code or test code, if OK starts with 1 steps to implement the next demand point or refine the function code.

In short, the TDD process is to write the test code that expects to implement the function first, and then the code to pass the test. Of course, the design is to give priority to testability, in order to ensure that the TDD process smoother.
The use of TDD thought development benefits have a lot, do not do a detailed introduction, interested in Baidu "TDD test-driven Development" keyword, a lot of information.
However, even with TDD, there are some test-related issues that inevitably arise during development:

• UT results ng, but the test program output information is difficult to locate the cause of the problem.
• The test conditions are confusing, causing the UT code to change frequently.
• Maintenance personnel are difficult to analyze the content of tests based on code.

These issues are difficult to avoid during the development process and can occur even if UT is discarded as the size of the code increases.
In order to reduce the occurrence of such problems, to control the trend of their growth, new ideas are introduced into the test development process-"behavior-driven development" (Behavior driven development, referred to as BDD).
BDD is a solution that, based on TDD, proposes to describe the behavior of the software in a way similar to natural language, so that the code is more closely related to the requirements specification and can be synchronized with the requirements, so the code is easy to understand and maintain.
According to the BDD a test case can be summarized as the following three stages, the test code also needs to be made according to the following three-paragraph context.

1. Given: Give a ... Prerequisites.
2. When: Execute ... After the action.
3. Then: So should get ... Results.

Now there are a lot of BDD-based testing frameworks, Java has Jbehave,ruby RSpec and cucumber,object-c have kiwi,swift have quick C + + has cppspec and so on. Based on these frameworks, we can write beautiful test code. is a test code written using the quick framework based on the swift language and a corresponding three-segment context description for reference:

Test Range

Theoretically, based on BDD, all the code needs to be tested, and UT is for "behavior" and should correspond to explicit function methods. But in the actual development process, there are many areas to be clear.

• There is an association between class objects, and the so-called "behavior" specifically requires which objects are involved.
• The functionality developed relies on how these "behaviors" are tested when third-party modules provide some interfaces.
• Usually the module that executes the test and the module that is tested are independent of each other, then what data and interface should be exposed by the tested module.

Here are some of the "dogmas" that determine the scope of the test, so-called dogma, which is simply flexible and does not have to be deliberately pursued:

1. The "behavior" of the test is simple, that is, the assert of a test case is better than a sentence.
2. Based on the behavior test, try not to expose the data, and if you want to test the data, you should test the method that provides the data (read-only computed properties in swift, equivalent to the method of providing the data).
3. The "behavior" of the test is internal, and the interface provided by the third-party module belongs to the external "behavior" and does not require testing.

In the development process, testing and design complement each other, the design needs to consider the testability of the program, the test can be seen whether the coupling between the module is too tight, the function of the module is single, thereby driving the architecture improvement, reduce the project later due to design problems caused by the reconstruction of the work number and the impact of the associated function. Therefore, in the design phase need to clear the scope of testing, the specification of the module and the "behavior", the corresponding test code will be simple and clear.

After you have defined the scope of the test, you need to make mocker for objects that are outside the scope of the test and depend on, as shown:

If you test module B, then you need to make a tester to test whether B's "behavior" satisfies the expected value in the perspective of user A. where modules C and D are dependent on B, it is necessary to make the corresponding mocker, providing an interface for use by B. Tester can verify that B's "behavior" is correct by confirming the data sent by B in the Mocker.

Test View

• Conditional test: When a conditional statement exists in the code, note the various status acknowledgements (that is, a combination of true and false) in the case of a multi-conditional expression combination. Pay attention to the short circuit evaluation condition.
• Boundary test: Pay attention to the definite interval (closed interval, open interval, semi-closed half-open interval), confirm the range of values, boundary values and out-of-bounds values, common arrays, comparison operations and so on.
• In addition to the 0 test: Note that the divisor may not be 0.
• Value out-of-bounds testing: Note value types (signed, unsigned, various types of value ranges).
• Null Object Test: Note whether there is a case where an empty object is being manipulated.
• Multiple return tests: Consider testing when a function or statement block has multiple exits.
• Illegal parameter test: Note that if there is an illegal entry, the function's action is normal.

Test criteria

1. Function coverage: whether each function in the measure program is executed.
2. Statement overlay (Statement coverage): Measures whether each executable statement in the code being tested is executed.
3. Branch coverage (Branch coverage): whether each of the determined branches in the measurement program is tested.
4. Conditional override (Condition coverage): The result of each sub-expression in a measure decision is true and false whether it is tested to

Naming conventions

• A test file contains a set of behavior descriptions (spec), so it is customary to use the target class to be tested as the name, with spec as the filename suffix.
• Describe describes the object content that needs to be tested, as well as the given in our three-segment.
• The context describes the test contexts, that is, when the test is in place, and a describe can contain more than one context to describe the behavior of the class under different scenarios.
• It is the test ontology that describes the conditions that the test should meet, and a context can contain multiple it test examples.

Some summary of UT