CN114741296A - Unit testing method, unit testing device, electronic equipment and storage medium - Google Patents

Abstract

The invention provides a unit testing method, a unit testing device, electronic equipment and a storage medium, wherein the unit testing method comprises the following steps: compiling and storing corresponding test case codes for development cases; pulling the test case code and compiling into FatJar; executing the test case in a FatJar reflection mode; and storing the execution result.

Description

Unit testing method, apparatus, electronic equipment and storage medium

technical field

This article covers but is not limited to the testing field.

Background technique

The general logic of basic components is very complex and requires a lot of testing to ensure the quality as much as possible.

In the prior art, development testers mainly use the following methods for unit testing:

(1) Write test cases based on Junit

Junit itself is very powerful and perfectly integrated with spring, it is the first choice for writing unit tests in the java field. But it can only be done manually within the code and is not well managed. Because it is generally written in the current project. So when new features are developed and new code branches are pulled, test cases are usually rewritten. Therefore, the test cases of the previous version may not be maintained and unavailable for a long time. In addition, new project branches generally only test the features of the current branch, resulting in incomplete test scenarios and difficulty in ensuring test quality. When positioning itself, it is functional testing, so management and automation are not considered. Especially with the iteration of the version, more and more functions, the code complexity is getting higher and higher, the management of unit tests is even more important.

(2) Write unit tests by yourself through code

Building test cases by yourself through code is more flexible and more suitable for some simple scenario tests. But for complex scenario testing, especially when relying on third-party components, it is extremely difficult and almost impossible. Therefore, the applicable scenarios are very limited, and there are no conditions for management and automation. It can only be used for the verification of some simple functions in the daily development process.

(3) Postman

Postman is a tool for simulating http calls. It also has the ability to store API calls, and this aspect is very powerful. In addition, it can store previously executed APIs and their parameters. Therefore, it has certain management capabilities, and some functions called by the front and back ends can be tested by postman. However, its usage scenarios are relatively limited for basic components and can only be used in the field of front-end interaction.

The version iteration of basic components is very fast, so the existing technology has not been able to solve the following serious problems:

1. A large number of unit test cases

2. Unit test case maintenance is difficult

3. Unit test cases are different between different versions

4. Regression testing of basic components is difficult

5. Unit test cases are hard to automate

Quality assurance of basic components has always been a difficult task. Many times when a new version is released, it is found that the previously fixed problems have reappeared, or new problems have appeared. Even the previously written test cases have been unable to run due to version changes, and the history cannot be verified. The existing technology is also insufficient for some UI terminals and some in-process behavior or state-related testing support. In addition, because it needs to be compiled into FatJar, the loading process will be longer. Therefore, a new test method is urgently needed.

SUMMARY OF THE INVENTION

An overview of various exemplary technical solutions is presented below. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of various exemplary solutions, but not to limit the scope of the invention. A detailed description of exemplary solutions sufficient to allow one of ordinary skill in the art to make and use the inventive concepts will be presented in subsequent sections.

In order to solve the above technical problems, the technical solution of the present invention provides a unit testing method, which includes: writing corresponding test case codes for development use cases and storing them; pulling the test case codes and compiling them into FatJar; Use case; stores execution results.

Preferably, the test case code further includes at least one of the following annotations: category-level annotations and method-level annotations.

Preferably, executing the test case by means of reflection of the FatJar further includes: loading the FatJar into the jvm through a custom classloader, and executing the test case by means of the reflection of the classes in the FatJar.

Preferably, it also includes outputting the execution result to the front end.

Another technical solution of the present invention provides a unit testing device, comprising: a test code writing module, configured to write corresponding test case codes for development use cases; a test code management module: configured to store test case codes; The management module is configured to pull the test case code from the test code management module, compile it into FatJar, and execute the test case through the reflection of FatJar; the database is configured to store the execution result.

Preferably, the test case code further includes at least one of the following annotations: category-level annotations and method-level annotations.

Preferably, the test code management module is GitLab.

Preferably, executing the test case by means of reflection of FatJar includes: loading the FatJar into the jvm through a custom classloader, and executing the test case by means of reflection of classes in the FatJar.

Another technical solution of the present invention also provides an electronic device, comprising: a processor, a memory, and a computer program stored and run on the memory, the processor implementing the method described in any one of the above technical solutions when the processor executes the computer program step.

Another technical solution of the present invention also provides a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method described in any one of the above-mentioned technical solutions are implemented.

The technical scheme of the present invention mainly has the following beneficial effects:

First, unit test cases can be centrally managed and maintained according to the basic component version.

Second, collections of test cases between different component versions can be automated and executed in parallel.

Third, historical unit test cases and the problem scenarios to be solved by the test cases at that time can be traced.

Description of drawings

For a better understanding of the various exemplary embodiments, reference may be made to the accompanying drawings, in which:

1 shows a schematic flowchart of a unit testing method provided by an embodiment;

FIG. 2 shows a schematic structural diagram of a unit testing apparatus provided by an embodiment.

To facilitate understanding, the same reference numerals have been used to refer to elements having substantially the same or similar structure and/or substantially the same or similar function.

Detailed ways

The description and drawings illustrate the principles of the invention. Accordingly, it will be appreciated that those skilled in the art will be able to devise various arrangements that, although not expressly described or illustrated herein, embody the principles of and are included within the scope of the invention. Furthermore, all examples cited herein are primarily intended to be expressly used for teaching purposes to assist the reader in understanding the principles of the invention and the concepts provided by the inventors to deepen the art, and all examples should be construed as not limiting Examples and conditions of such specific citations. Also, as used herein, the term "or" refers to a non-exclusive or (ie, and/or) unless otherwise indicated (eg, "or otherwise" or "or in the alternative"). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

Glossary:

JUnit: JUnit is an open source Java testing framework for writing and running repeatable tests. It is an instance of xUnit for the unit testing framework system (for the java language). It includes the following features: 1. Assertion for testing expected results; 2. Test tools for sharing common test data; 3. Test suites for easy organization and running of tests; 4. Graphical and textual test runner

GitLab: GitLab is an open source project for a warehouse management system, using Git as a code management tool and building a web service on this basis. The installation method is to refer to GitLab's wiki page on GitHub.

Classloader: Classloader class loader, a loader used to load Java classes into the Java virtual machine.

FatJar: FatJar is a jar package that contains all project class files and resources and all dependencies.

The first embodiment provides a unit testing method, see FIG. 1 , the method includes:

Step S101: write the corresponding test case code for the development case and store it;

There are many application program interface APIs in the application program, and each API has one or more test cases corresponding to it. Each development version corresponds to a test version.

GitLab or other suitable code management tools can be used (GitLab is used as an example below) to store unit test code separately by branch. One branch corresponds to one version release or major feature improvement. First, create a development branch to generate corresponding test branches for development use cases. Write the corresponding test case code and store it. Associate the development branch with the test branch. Unit test cases can be based on Junit, or can be implemented based on other test frameworks. The following uses Junit as an example.

Each unit test case can additionally add custom annotation annotation, annotation classification level and method level 2 dimensions.

The class level mainly describes the author of the class and the purpose of the class, as well as the category to which it belongs. as follows:

The method level mainly extends some characteristics of the method itself, such as the name, the test scenario corresponding to the use case, the author, and some additional expressions of the method (mainly used for query, statistics, etc.). as follows:

Additional attributes are defined, which can specifically define the purpose of the test case, what it does, and what the result is, and map the attributes to the test case. Enhanced Junit unit test properties to better manage unit test cases.

Step S102: pull the test case code and compile it into FatJar;

GitLab pulls development branches and corresponding test branches. Junit unit test cases related to basic components can be maintained in a separate project, or can be an independent module in a project. When users want to execute a unit test case from the console, they need to pull the relevant test case branch code from GitLab, and then compile it into FatJar.

The traditional Junit can only be in the development environment code, there is no way to call a single test case, you must call multiple test cases in a class. Junit code can be modified to support external trigger calls, so that it can support automatic reflection calls and execute test cases. The source code has been changed, and any use case can be executed externally independently.

In addition, the plugin maven pom.xml file must add FatJar packaging related configuration, otherwise it may not be possible to call test cases by loading FatJar, as follows:

Instead of putting test cases into the project, they are compiled into FatJar for unified management and triggered individually. Each test test is associated with the development test, which can be traced and managed.

Step S103: execute the test case by means of the reflection of FatJar;

FatJar contains all the classes. The system will load the FatJar into the jvm through the custom classloader, call it through the reflection of the classes in the FatJar, and execute the relevant test cases.

Users can bind the unit test git address and project branch in the console to facilitate future management.

When users need to test a development version of the project, they can first select the test project, then obtain all branches of the project, and then obtain the git address of the corresponding unit test case according to the project branch.

Then pull the code from the git remote to the local, compile it into FatJar, and store the FatJar in the local path. The reason for compiling into FatJar is because different component versions may depend on different third-party package versions. If you use the system's own version jar package, on the one hand, the test case may not be executed due to the version problem, and on the other hand, it is necessary to continuously add the jar package that needs to be dependent, which increases the cost virtually.

Then load the FatJar into the jvm through the custom classloader, traverse all the unit tests, manage and maintain the unit test information according to the annotation, and can view it from the front end. And according to the test case selected from the front end, it can be invoked through reflection to execute the test case.

Step S104: Store the execution result.

After the test case is executed, the execution result is stored in the database and output to the front end (such as the user end) for query.

According to GitLab to manage unit test cases, it is agreed that the branch of each basic component corresponds to a branch of the unit test case. The secondary development of Junit enriches the basic properties of unit tests by customizing annotations, and supports loading the unit test collections that have been packaged into FatJar through different classloaders by modifying the source code, so as to not only realize the isolation between classes, but also have external The ability to trigger calls, thereby enabling automated execution of test cases.

The second embodiment provides a unit testing apparatus 200 , referring to FIG. 2 , including: a test code writing module 201 , a test code management module 202 , a test case management module 203 , and a database 204 .

The test code writing module 201 is configured to write corresponding test case code for the development use case;

Test code management module 202: configured to store test case codes;

There are many application program interface APIs in the application program, and each API has one or more test cases corresponding to it. Each development version corresponds to a test version.

GitLab or other suitable code management tools (GitLab is used as an example below) can be used as the test code management module 202, and the unit test code is stored separately according to the branch. One branch corresponds to a version release or major feature improvement. Test branch, write the corresponding test case code for the development case and store it. Associate the development branch with the test branch. Unit test cases can be based on Junit, or can be implemented based on other test frameworks. The following uses Junit as an example.

Each unit test case can additionally add custom annotation annotation, annotation classification level and method level 2 dimensions. The class level mainly describes the author of the class and the purpose of the class, as well as the category to which it belongs. The method level mainly extends some characteristics of the method itself, such as the name, the test scenario corresponding to the use case, the author, and some additional expressions of the method (mainly used for query, statistics, etc.). Defines additional attributes, specifically defines the purpose of the test case, what it does, and what the result is, and maps the attributes to the test case. Enhanced Junit unit test properties to better manage unit test cases.

The test case management module 203 is configured to pull the test case code from the test code management module 202 and compile it into FatJar; and execute the test case through the reflection of FatJar;

The test case management module 203 is configured to pull the test case code from the test code management module 202 . Junit unit test cases related to basic components can be maintained in a separate project, or can be an independent module in a project. When users want to execute a unit test case from the console, they need to pull the relevant test case branch code from GitLab, and then compile it into FatJar.

The traditional Junit can only be in the development environment code, there is no way to call a single test case, you must call multiple test cases in a class. Junit code can be modified to support external trigger calls, so that it can support automatic reflection calls and execute test cases. The source code has been changed, and any use case can be executed externally independently.

In addition, the plugin maven pom.xml file must add FatJar packaging related configuration, otherwise it may not be possible to call test cases by loading FatJar.

The test case management module 203 does not put test cases into the project, but compiles them into FatJar for unified management and triggers them individually. Each test test is associated with the development test, which can be traced and managed.

FatJar contains all the classes. The test case management module 203 loads the FatJar into the jvm through the custom classloader, invokes it through the reflection of the classes in the FatJar, and executes the relevant test cases.

Users can bind the unit test git address and project branch in the console to facilitate future management.

When users need to test a development version of the project, they can first select the test project, then obtain all branches of the project, and then obtain the git address of the corresponding unit test case according to the project branch.

Then pull the code from the git remote to the local, compile it into FatJar, and store the FatJar in the local path. The reason for compiling into FatJar is because different component versions may depend on different third-party package versions. If you use the system's own version jar package, on the one hand, the test case may not be executed due to the version problem, and on the other hand, it is necessary to continuously add the jar package that needs to be dependent, which increases the cost virtually.

Then load the FatJar into the jvm through the custom classloader, traverse all the unit tests, manage and maintain the unit test information according to the annotation, and can view it from the front end. And according to the test case selected from the front end, it can be invoked through reflection to execute the test case.

The database 204 stores execution results.

After the test case is executed, the execution result is stored in the database 204 and output to the front end for query.

A third embodiment also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and running on the memory, where the processor implements the steps of the method in any of the foregoing embodiments when the processor executes the computer program, for example, step S101 to S104, or when the processor executes the computer program, the functions of the modules/units in the foregoing embodiments, for example, the functions of the units 201 to 204, are implemented. The computer program may be divided into one or more modules/units, which are stored in the memory and executed by the processor. The one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

The electronic device may be a mobile terminal such as a smart phone, or a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server. The electronic device may include, but is not limited to, a processor, a memory, more or less components, or a combination of certain components, for example, the electronic device may also include an input and output device, a network access device, a bus Wait. The processor may be a central processing unit (Central Processing Unit, CPU), other general-purpose processors, a digital message queue manager (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC) , Off-the-shelf programmable gate array (FieldProgrammable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The memory may be an internal storage unit of the electronic device, such as a hard disk or a memory of the electronic device. The memory may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a Secure Digital (SD) card, a flash memory equipped on the electronic device Card (FlashCard) and so on. Further, the memory may also include both an internal storage unit of the electronic device and an external storage device.

The fifth embodiment also provides a computer-readable storage medium, when the computer program is executed by the processor, the steps of the method of any of the above-mentioned embodiments are implemented.

Each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units. The integrated modules/units, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the processes in the methods of the above embodiments, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer When the program is executed by the processor, the steps of the foregoing method embodiments can be implemented. Wherein, the computer program includes computer program code, and the computer program code may be in the form of source code, object code, executable file or some intermediate form, and the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, removable hard disk, magnetic disk, optical disk, computer memory, Read-Only Memory (ROM) , Random Access Memory (Random Access Memory, RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable media may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer-readable media Electric carrier signals and telecommunication signals are not included.

Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. Module completion, that is, dividing the internal structure of the device into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment may be integrated in one processing unit, or each unit may exist physically alone, or two or more units may be integrated in one unit, and the above-mentioned integrated units may adopt hardware. It can also be realized in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing from each other, and are not used to limit the protection scope of the present application. For the specific working processes of the units and modules in the above-mentioned system, reference may be made to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

In the foregoing embodiments, the description of each embodiment has its own emphasis. For parts that are not described or described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments. Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application.

In the embodiments provided in this application, it should be understood that the disclosed systems, electronic devices and methods may be implemented in other manners. For example, the above-described system and electronic device embodiments are only illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units. Or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of systems or units, and may be in electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the above-mentioned embodiments, those of ordinary skill in the art should understand that: it can still be used for the above-mentioned implementations. The technical solutions described in the examples are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions in the embodiments of the application, and should be included in the within the scope of protection of this application.

Claims (10)

1. a unit testing method, is characterized in that, comprises: Write the corresponding test case code for the development use case and store it; Pull the test case code and compile it into FatJar; Execute test cases through FatJar reflection; Store the execution result. 2 . The unit testing method according to claim 1 , wherein the test case code further comprises at least one of the following annotations: a classification-level annotation and a method-level annotation. 3 . 3. unit testing method according to claim 1, is characterized in that, the described mode of reflection by FatJar executes test case also comprises: by self-defined classloader, FatJar is loaded in jvm, by the mode of reflection of class in FatJar Execute the test case. 4. The unit testing method according to claim 1, further comprising outputting the execution result to the front end. 5. A unit testing device, comprising: The test code writing module is configured to write the corresponding test case code for the development use case; Test code management module: configured to store test case code; The test case management module is configured to pull the test case code from the test code management module, compile it into FatJar, and execute the test case through the reflection of FatJar; A database, configured to store execution results. 6 . The unit testing apparatus according to claim 5 , wherein the test case code further comprises at least one of the following annotations: a classification-level annotation and a method-level annotation. 7 . 7. The unit testing apparatus according to claim 5, wherein the test code management module is GitLab. 8. The unit testing device according to claim 5, wherein the execution of the test case by means of the reflection of FatJar comprises: loading the FatJar into the jvm through a custom classloader, and executing by means of the reflection of the class in the FatJar test case. 9 . An electronic device, comprising: a processor, a memory, and a computer program stored in the memory to run, the processor implements the method of any one of claims 1-4 when the processor executes the computer program. 10 . 10. A computer-readable storage medium, wherein, when the computer program is executed by a processor, the method of any one of claims 1-4 is implemented.

Images