Shulou(Shulou.com)06/02 Report--

This article focuses on "Overview and practice of Java SDK integration testing". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the overview and practice of Java SDK integration testing.

Project background

As a professional team focused on the design and R & D of the underlying platform of block chain for a long time, interest chain Technology pays special attention to product quality. Software testing can be said to be the most critical part of the quality assurance of the platform.

The underlying technology platform usually provides interactive SDK. In the testing process, the system can be integrated and tested through SDK to verify whether the functions of the system can be used normally.

Java SDK is the most widely used category in software development. Based on the practice of BitXMesh project testing, this paper introduces some experiences of Java SDK integration testing.

The main functions provided by the system are as follows:

Resource management in resource repository, including file / database / model / Restful interface, etc.

Federal computing

Cross-node resource acquisition and display

System and user management

At first, the testing tools are relatively fragmented, but after adding modules or functions, they tend to build a new small test project for testing. However, with more and more functions and customers, the requirements of quality assurance can not be relaxed, so it is necessary to build a perfect test project.

Taking the project as an example, this paper introduces in detail the analysis, planning, implementation, specific module examples and the final test report of the test project.

Test project analysis

In the test project, the core link is the test case design. In order to design an elegant test case, we must first have a full understanding of the project itself. According to the analysis of the function and code structure of the project, the test project use case structure is divided into the following three categories:

User rights related tests: verify that different types of users have normal permissions for module operations

Abnormal data testing: including data exceptions and functional logic exceptions

Normal function test

It is not difficult to implement a separate use case.

However, follow-up maintenance should be fully taken into account, especially permission testing and exception testing.

Therefore, the following two principles should be adhered to when designing test cases:

Optimize code structure, reduce code redundancy and increase readability

Test case data and test code are separated, so it is convenient to maintain test cases separately.

Test project planning test framework

TestNG is an open source automated testing framework inspired by JUnit and NUnit, but it introduces some new features to make it more powerful and easier to use. It largely draws on Java annotations to define tests.

This project is tested with TestNG. Excel maintains the use case data, encapsulates the function to read the data, and uses dataProvider to pass it to the test function for testing.

Data-driven testing, function parameter transfer form

Because of the strong functional coupling of the system, a single use case often contains more operations. We combine the test cases of similar processes together, number the locations of each operation, pass parameters in the form of Pair, and assert the location of the expected exception.

Exception capture and handling during testing

For permission-related tests, each operation may or may not have permission, so after each operation is completed, it can be directly compared with the expectation, and the error code will be asserted when an exception is caught.

For the test related to the process, if the previous operation has an impact on the later operation, directly assert the error code after it is detected that the operation throws an exception, then exit the current test and continue the later test; otherwise, continue the later operation.

Automatically trigger Jenkins project build

Use triggers to perform automatic builds. For more information, please see Section 6 [continuous Integration].

Project structure

Organization of use cases

Test cases are written in tabular form in the internal Thoughts environment, and the use cases are derived from requirements documents and system test analysis documents.

Test project structure

Use the project management tool Maven to manage builds and reports in this project.

Version control

The version number is consistent with the version number of the project under test and is maintained in Git.

Partial implementation example

There are many different types of users in BitXMesh, and these users have different permissions for different modules and resources, so you need to test the permissions one by one to see if there are any omissions or ultra vires.

In addition, there are restrictions on some input information in BitXMesh requirements, such as length / empty / repetitive / special format, etc., boundary values and other related logic need to be tested.

Permission test (with a unified error code)

The permissions in the module mainly include create / delete / view / modify / upload / download / empowerment operations.

Because creation is the basis of later operations, a separate use case is specified to test the permissions of the creation function; other operations share a use case, and when the use case is executed by different users in each round, let the designated user create it first and then perform the later actions.

All permissions of a user in a module are taken as a set of test data; the operation with permission is completed normally, and an exception is thrown when there is no permission, and the status code is the specified value; after obtaining the error information, you can make an assertion comparison of each abnormal status code captured, and the current test continues.

Exception data testing (with special error code)

The function of the module is tested in the whole process here. When the test program catches an operation that throws an exception, it returns directly and does not perform subsequent tests.

To facilitate data-driven testing, we mark the order of each operation in the use case, incrementing from 1; if we expect to catch an exception at the nth operation, we can pass in (n, errCode) for assertion verification

Continuous integration of Jenkins configuration

Write deployment scripts to run integration tests using the shell command

Trigger flow

After Git webhook detects the merging of tag or trunk branches, it triggers the upstream Jenkins packaging task, generates an executable file, and pushes it to the Nexus warehouse.

After the task of generating the executable file is successful, the integration test task is triggered, the executable file is pulled remotely, and the deployment and testing are performed.

Program running environment

The Docker container provided by the Jenkins slave node. Because a single BitXMesh does not take up a lot of resources, you can run test programs and multiple BitXMesh node programs simultaneously in a single Docker container.

Test report

This project uses the maven plug-in maven-surefire-plugin to generate test reports. After the project test is completed, the target/surefire-reports/emailable-report.html report is automatically generated and the corresponding test report path is specified in Jenkins.

The configuration in pom.xml is as follows:

Summary

Permission testing and exception testing are two points that need to be paid attention to in the testing process, which need to be planned in advance in automated testing.

The former is easy to lead to bloated code; the latter is difficult to consider all at once and needs follow-up maintenance. The problems of these two blocks can be solved through reasonable data-driven testing, and a relatively perfect automated testing can be achieved by adding some engineering methods.

Most testers are beginners of interface functional testing, and it takes some time to understand background service testing.

The essence of Java SDK is to encapsulate the system call interface into a class library for use by clients; when conducting integration testing, you need to be familiar with SDK usage documents in advance, and then plan through a hierarchical architecture.

At this point, I believe you have a deeper understanding of "Overview and practice of Java SDK integration testing". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.