Interface testing is an essential part of all development testing. Effective and fully covered interface testing not only ensures the quality of new feature development, but also gives developers the ability to regression when modifying functional logic, and is a prerequisite for elegant refactoring. What are the guidelines for writing interface tests? What should the structure of the test code look like? What are some practical tips for interface testing? This article shares a summary of the author’s practice on interface testing.

Front-line developers may more or less cause online bugs or even faults; There are also scenarios where a student reconstructs the code while developing a certain function, resulting in online bugs or faults. When you’re developing a feature, you find that you need to change the common logic, and you’re afraid of affecting other features, and you unsightly copy code and rewrite it to support separate logic.

In each of these cases, a key issue is how to ensure the quality of code development, whether functional development or logical refactoring. The safeguard, as everyone knows, is testing. First is the new function test, to ensure the new function logic is correct; The second is regression testing to ensure that the original business function logic is correct. There are two ways of testing, manual testing and automated testing. With the continuous development of testing technology and tools, the proportion of manual testing is gradually reduced and replaced by automated testing. Automated testing is sustainable and repeatable, even ai-able.

Test stratification

The tests are also layered, as shown below:

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. Unit tests are basically tests of a single method of a single class, and are too expensive to write in our current model. Of course, if it is a tool or a piece of cohesive and complex logic (such as algorithmic logic), unit tests should be used to ensure that the logic is correct.

Module test

When the system is large and there are many modules, the module test layer can be established to ensure the correctness of each module function. However, the current development trend of the system is microservice architecture, so the module test layer is not very necessary, can be covered by the interface test layer.

The interface test

In my opinion, it should be called entrance test accurately. This layer is the integration test starting from the system entrance. Application portals are usually HSF (a distributed RPC services framework) services, messages, and scheduled tasks.

As a development, testing means thousands of, interface testing is indispensable. Under the condition that the interface test we applied is effective and complete, we can not only guarantee the development quality of our new functions, but also enable us to have the ability of regression when modifying the functional logic, which is also the premise of code reconstruction. At the same time, testability is also an indicator of reasonable code structure. If a piece of code is found to be difficult to write test scripts or cannot be tested, it indicates that the current code structure is unreasonable and needs to be reconfigured. Next, I’ll focus on the effectiveness of interface testing.

Ii Test Principles

Basic Principles:

  • Automation: Interface tests are performed in a non-interactive, automated manner without human involvement.

  • Independence: Interface tests should not depend on each other.

  • Repeatable: Interface tests can be executed repeatedly and are not affected by the environment.

  • Interface testing complies with BCDE principles to ensure interface delivery quality.

  • Border: indicates the Border test.

  • Correct: Correct input, Correct expected output.

  • Design: Write test logic according to requirements and Design documents.

  • Error: Indicates incorrect input and expected output.

  • Data preparation: Data preparation is performed by using system services, not by directly inserting the DATABASE.

  • Testability: Untestability code needs to be restructured properly.

  • Coverage: The interface test must cover all UC, and the code coverage and branch coverage must meet certain standards. New code must be covered.

  • Persistence: If a code change causes an existing interface test to fail, fix the code problem or test the code logic.

  • Time requirement: Interface testing should be completed before the project is released, not after.

The above basic principles should apply to automated test cases at all levels. In addition to these principles, there are other principles to follow when writing interface tests.

Analyze entry calls from a system perspective, using HSF services as an example:

  • Peripheral system calls services provided by our system.

  • The system executes a bunch of code logic, including branch logic.

  • System execution relies on external HSF services, calls are made, and returns values.

  • System execution process depends on DB query or landing data, depends on cache query or landing data.

  • A message is sent during system execution. Procedure

  • Return HSF execution results to upstream system.

The key principles of effective interface testing are to override all entries, mock all dependencies, and verify any traces left during execution, summarized as follows:

  • Entry coverage: Interface test cases must cover HSF service entry, message entry, and scheduled task entry.

  • Dependency mock: One of the basic principles that can be repeated is that interface tests cannot be dependent on the environment and need to mock out external dependencies. However, for DB dependencies, complete mocks are not recommended because mocks are expensive and may not cover SQL and table constraint logic.

  • Validation integrity: a valid interface test should have complete validation. An interface test without validation is meaningless. To ensure the validity of interface tests, verify all traces that affect services.

  • HSF interface return value verification: Verifies HSF return parameters based on scenarios and interface conventions.

  • DB verification: Verifies the correctness of landing data.

  • Cache verification: Verifies the correctness of data stored in the cache.

  • HSF dependency input verification: Use the mock tool to obtain the input parameters of HSF dependent calls and verify the input parameters.

  • Message verification: Use the mock tool to obtain the sent message object and verify the message body.

If you are interested in software testing and want to learn more about testing, solve testing problems, and get started with guidance to help you solve the puzzles encountered in testing, we have technical experts here. If you are looking for a job or just out of school, or have already worked but often feel a lot of difficult, think that their test learning is not enough, want to continue learning, want to change careers afraid of learning not, can join us 1079636098, In the group, you can get the latest software test factory interview materials and Python automation, interface, framework building learning materials!

Test code structure

When writing test code, you should consider the same things as when writing business code: readable, extensible, and reusable code. At the same time, according to the business characteristics of the system, the test components suitable for the current system can be encapsulated on the basis of the test framework, so as to improve the test code writing efficiency and standardize the test code structure.

An interface test code, the approximate structure is as follows:

1 Test Preparation

Dependent Data Preparation

Many times, our tests have data dependencies, either configuration data or business data (for example, refunds need to rely on payment data).

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

  • Business data: This type of data should not be generated by directly inserting data, but should be generated by invoking business services.

Relying on the mock

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

Prepare interface test input parameters

Prepare input parameters for the interface.

2 Test Execution

Invoke the interface method to execute the business logic.

3 Test and Verification

  • Returned parameter Verification: The returned parameter of the verification interface.

  • DB: verifies the landed DB data.

  • Cache data verification: Verifies data dropped into the cache.

  • Message verification: Verifies the sent message object.

  • Verification of HSF invocation: Verifies the input parameters of HSF invocation.

Four Practical Skills

1 Execution Efficiency

For interface test, the execution efficiency is a point we have to pay attention to. If an interface test is executed for more than 3 minutes, the result can be seen, which will greatly reduce the enthusiasm of the developer students to write interface test. For the improvement of test execution efficiency, the proposed scheme is as follows:

  • Minimize the startup test context, such as spring Boot applications, and just start Spring

  • Use an in-memory database, such as H2

  • Mock out middleware dependencies

2 Test framework selection

For a testing framework, you are advised to select a testng based testing framework that provides data preparation from configuration files. If you can’t find one, you can encapsulate it yourself based on Testng.

3 Interface test coverage

The completeness of the scenario affects the coverage of test cases. On the one hand, the developer needs to enumerate the normal and abnormal conditions based on the input and testing experience of the business scenario; on the other hand, the interface method also has some fixed points to be tested, such as idempotence test, boundary value test, parameter incorrect test and so on.

At the same time, the coverage tool should be used to view the code or branch logic not covered by the interface for specific scenario coverage testing. In my experience, complete branch coverage is very important, especially for exception branches.

Five summarizes

In order to ensure the stability of system online operation, quality assurance means are indispensable. While there are many automated safeguards, interface testing remains one of the most basic and important safeguards. If the coverage and effectiveness of interface test can be continuously guaranteed, the generation of online bugs will be reduced to a large extent, and the developers will be more motivated to reconstruct the code.

Finally:

The future of you will certainly thank now desperately own!

To recommend a software testing technology exchange group: 1079636098 group benefits free

I wish you and I meet, both gain! Welcome to wechat public account: Programmer Yifan

1. Receive a free 216-page software test engineer interview guide.

2. Software test learning route and corresponding video learning tutorial free to share!