Integration test practice (1) theoretical basis

How procedural apes view self-test ？ Why pay attention to testing ？ How to test ？ This paper summarizes the relevant issues , Much of it comes from the geek time column 「 Programmer's testing class 」. The next article focuses on the practice of integration testing .

1. Why write tests ？

The key reason ： Software development is becoming more and more complex . Testing allows us to move steadily forward in increasingly complex software development .

• When writing new functions , Testing can verify the correctness of our code , Let's have stable modules .

• Testing can help us continue to return in the long-term process , Let each step go more steadily . Isolate change , Write stable code step by step .

2. Why should programmers write tests ？

Programmer's test VS Tester's test

Programmers focus on white box testing , And the tester is black box testing .

The starting point of programmers is to realize , The starting point of testers is business . As a programmer , We will spend more time thinking about technology implementation , Our training intensity in finding problems is far from enough . therefore , People often say that , Don't challenge others' eating skills with your hobbies .

Every time programmers think a little more , The software quality can be improved a little more .

The testers didn't give full play . Only programmers do their own tests , Only in this way can testers be freed from daily trivial verification work , To do more valuable tests .

3. Unit test best practices

a key ： Code and tests are written together

• Ensure test quality ： The whole function code has been written , Then write the test , It's hard for you to remember all the details when writing this pile of code , At this time, the supplementary tests are not very helpful to improve the code quality .

• The granularity of work should be small ： The granularity of writing all the functions is too large . Write tests for a big task , Is a very difficult thing , This is also an important factor that many people find it difficult to write tests .

• Minimize constraints on implementation details ：mock when , Tend to use broader constraints . To some extent, this will reduce the impact of refactoring code in the future .

4. Make sure you write your own code 100% Test coverage

1. Have a testable design , Make sure your code is completely controllable

2. Test and code are written synchronously

3. Isolate hard to test code ： For code that cannot be tested to a third party , Use a thin isolation layer to isolate the code , Exclude the isolation layer from the build script .

5. Integration testing

even 100% Unit testing of can't solve all the problems . An important reason is , When we write each unit, we assume that these units can work well with each other , But is this assumption necessarily true ？ The answer is not necessarily . In addition to ensuring the correctness of the unit , We also need to ensure that the collaboration between units is also correct . As opposed to unit testing, it only focuses on unit behavior , Integration testing focuses on the performance of multiple components working together .

5.1 The significance of integration testing

• To ensure the correctness of collaboration between components ;

• You need to use the same assembly process as the product code ;

• You can take the tested stable components as the basis .

5.2 Two integration issues and best practices

5.2.1 Integration between codes

1) Choose a path for task execution , Integrate the components used on the path for testing .

After the unit test is completed , It means that every component has been tested . therefore , The focus of integration testing is no longer the collaborative testing between components .

2) Integrate the framework , Do a complete integration test .

Integrate as much as possible , As close to the real scene as possible . If we can integrate the whole framework , These things can also be verified .

3) Integration logic between components , Unit tests are not required

This part of code is actually just a simple encapsulation of business logic , The main work is information forwarding , This will be a very thin layer . For practical reasons , Here we use integration testing instead of unit testing , Simplify test writing .

5.2.2 Integration of code with external components

1) You can't modify the code for the needs of testing

If you really want to modify , Maybe what should be modified is the design , Not just code . There can be no special logic in business code just to run through a test case .

6. Test the proportioning model

6.1 Ice cream cone model

The starting point of ice cream cone is to consider the coverage of a single test , Just some system testing , It is enough to cover most situations of the system . Of course , For those scenarios that cannot be covered by system testing, low-level test cooperation is required , such as , Integration testing and unit testing . In the ice cream cone model , The main force is high-level testing , Low level testing is just a supplement to high-level testing .

6.2 Test the pyramid model

6.3 Best practices

The new project ： Use the test pyramid model , Write tests layer by layer . Each function is completed , Code and tests are always written synchronously , Code is always validated , So we can move forward steadily .

Legacy projects ： Start with system testing , Just write some high-level tests , It can cover most functions of the system , Can quickly establish a safety net , Belong to “ Less investment, quick results ” How to do it . After having the bottom line of a safety net , We still have to move towards the test pyramid , Take unit testing as the basis of the whole .

7. Write test best practices

7.1 The goal of our testing is our code , Not external dependencies

Due to other libraries 「JDK、 Two party Library 、 Three party Library 、RPC etc. 」 Cause problems that are difficult to test , We can make thin layers of packaging , then , Ignore it in the coverage check . Encapsulation and neglect , Be short of one cannot .

7.2 Write testable code

• Make your code conform to software design principles .

• Write composable code .

  • Don't create objects inside components , Component assembly uses dependency injection .

  • Constructor Injection VS Field injection

8. Best practices for transforming legacy systems

Legacy systems are those that have not been tested , Writing tests for legacy systems is the process of getting a system back to normal .

1. It is difficult to write tests for a legacy system completely . A practical improvement strategy is , Where to move , Change where .

2. The key to transforming legacy systems is decoupling . For heavily coupled objects , Extraction method , Move to an encapsulated class . Write composable code .

9. unit testing 、 Integration testing 、 System test comparison

9.1 unit testing

describe ： Developers complete , Write tests for units , The particle size should be as small as possible , It's usually a method 、 One class .

The goal is ： Ensure that every part is stable .

Number of cases ： most

9.2 Integration testing

describe ： Usually developers complete , Integrate multiple units for testing , Generally, complete functional modules are tested . General integration Spring Containers 、 In-memory database 、 has Mock External dependence of .

The goal is ： Ensure that the functional modules are stable . Do not pay attention to whether the parts in the module are stable 「 This is the work of unit testing 」.

Number of cases ： Less

9.3 The system test

describe ： The tester completes , Integrate the whole system completely , Can automate the execution of . Don't pay attention to implementation details , Pay attention to whether the requirements are realized .

practice ： Test the whole application in the test environment , Don't do external dependencies Mock.

The goal is ： Ensure that the complete business is stable . Theoretically, there is no need to pay too much attention to details 「 unit testing 、 Integration testing theoretically does these , But in fact, system testing still needs to pay attention to details 」

Number of cases ： Less

10. Reference material

1. Geek time - special column - Programmer's testing class