Shulou(Shulou.com)05/31 Report--

In this article, the editor introduces in detail "how to write an effective interface test in spring". The content is detailed, the steps are clear, and the details are handled properly. I hope this article "how to write an effective interface test in spring" can help you solve your doubts.

One test layering

The tests are also hierarchical, as shown in the following figure:

In a system, automated testing is generally divided into unit testing, module testing and interface testing.

Unit testing

At present, my application code is basically based on the interface-oriented programming mode of spring framework, and unit testing has been weakened. The requirements of unit testing are basically the testing of a single class and a single method, and in our current mode, the cost of writing is too high. Of course, if it is a tool or a piece of cohesive and complex logic (such as algorithmic logic), you should use unit tests to ensure the correctness of the logic.

Module testing

In the case of a large system and many modules, a module test layer can be established to ensure the correctness of the functions of each module. However, the current system development trend is micro-service architecture, so the module test layer is not very necessary and can be covered by the interface test layer.

Interface test

Personally, I think it should be called entrance testing, and this layer starts from the system entrance for integration testing. Application portals are usually HSF (a distributed RPC services framework) services, messages, and scheduled tasks.

As a means of development and testing, interface testing is indispensable. Under the condition that the interface testing of our application is effective and complete, it can not only ensure the development quality of our new functions, but also let us have the ability of regression when modifying functional logic, which is also the premise for us to do code refactoring. At the same time, testability is also an indicator of reasonable code structure. if it is found that it is difficult to write a test script or cannot be tested, it means that the current code structure is unreasonable and needs to be refactored. Next, I will focus on the effectiveness of interface testing.

Second, testing principles

Basic principles:

Automation: interface testing is a non-interactive automated execution that does not require human participation.

Independence: interface tests should not depend on each other.

Repeatable: interface tests can be repeated without being affected by the environment.

Interface testing complies with the BCDE principle and ensures the quality of interface delivery. Border: boundary test. Correct: correct input, correct expected output. Design: write test logic according to requirements and design documents. Error: incorrect input, expected output.

Data preparation: data preparation is done through system services, not directly into db.

Testability: code that is unmeasurable needs to be restructured into a reasonable structure.

Coverage: interface testing needs to cover all UC, while code coverage and branch coverage should meet certain standards, and new code must be covered.

Persistence: if code modifications cause the execution of existing interface tests to fail, you must fix code problems or test code logic.

Time requirement: interface testing should be completed before the project release and should not be added after the project release.

The above basic principles should apply to all layers of automated test cases. When writing interface tests, there are other principles to follow. First, take a look at a diagram:

Analyze the entry invocation from a system point of view, taking HSF service as an example:

The peripheral system calls the services provided by our system.

The system executes a pile of code logic, which contains branching logic.

In the process of execution, the system relies on external HSF services, calls are made, and the return value is obtained.

In the process of execution, the system relies on DB query or landing data, and depends on cache query or landing data.

A message was sent during the execution of the system.

Returns the HSF execution result to the upstream system.

The key principle of effective interface testing is to cover all entrances, all mock dependencies, and verify the traces left during execution, which are summarized as follows:

Entry coverage: the interface test case must cover the HSF service entry, message entry, and timing task entry.

Dependence on mock: in the basic principle, there is a repeatable principle, that is, interface testing cannot be dependent on the environment, and mock is required to eliminate external dependence. However, for db dependencies, complete mock is not recommended. On the one hand, the cost of mock is high, and on the other hand, it may not be able to cover sql and table constraint logic.

Verification integrity: effective interface testing should have complete verification. Interface testing without verification is meaningless. As long as the traces left in the implementation process have an impact on the business, a complete verification must be carried out in order to ensure the effectiveness of the interface test. HSF API return value verification: check the HSF return parameters according to the scenarios and API conventions. DB check: check the correctness of the landing data. Cache check: verify the correctness of the data stored in the cache. HSF dependent input parameter verification: the input parameter dependent on HSF call is obtained through the mock tool, and the input parameter is verified. Message verification: the message object sent is obtained through the mock tool, and the message body is checked.

Three test code structure

When writing test code, you should consider the readability, extensibility, and reusability of the code as well as writing business code. At the same time, according to the business characteristics of the system, we can encapsulate the test components suitable for the current system on the basis of the test framework, improve the writing efficiency of the test code and standardize the test code structure.

The test code for an interface is roughly structured as follows:

1 Test preparation

Dependent data preparation

In many cases, our tests rely on data, which may be configuration data or business data (for example, refund depends on payment data).

Configuration data: you can initialize the configuration by defining a configuration file.

Business data: this kind of data is not allowed to be generated by inserting data directly, but should be generated by invoking business services.

Rely on mock

For external dependencies, you need to mock the dependent services to avoid actual invocation.

Interface test input parameter preparation

Prepare the input parameters for the interface.

2 Test execution

Call the interface method to execute the business logic.

3 Test check

Return parameter check: verify the returned parameters of the API.

DB: verify DB landing data.

Cache data check: check the data that has landed in the cache.

Message verification: verifies the message object sent to the outside.

External HSF call verification: verifies the input parameters of external HSF calls.

Four practical skills

1 execution efficiency

For interface testing, execution efficiency is a point that we have to pay attention to. If an interface test runs for more than 3 minutes to see the results, it will greatly reduce the enthusiasm of developers to write interface tests. For improving the efficiency of test execution, the recommended solutions are:

Minimize the startup test context, such as the application of spring boot, and start spring.

Use an in-memory database, such as H3

Get rid of middleware dependence on mock

2 selection of testing framework

For the testing framework, it is recommended to choose a testng-based testing framework that can provide data preparation through configuration files. If you can't find a suitable one, you can encapsulate it yourself based on testng.

3 interface test coverage

The integrity of the scenario affects the coverage of test cases. On the one hand, developers need to enumerate normal and abnormal cases based on the input and test experience of business scenarios, and on the other hand, interface methods also have some fixed points that need to be tested, such as idempotent testing, boundary value testing, incorrect parameter testing, and so on.

At the same time, we should also use the coverage tool to view the code or branch logic that is not covered by the interface, and conduct targeted scenario coverage testing. In my experience, full branch coverage is very important, especially for abnormal branches.

After reading this, the article "how to write effective interface tests for spring" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.