Unit test methods, apparatus, electronic devices and storage media

Abstract

This invention provides a unit testing method, apparatus, electronic device, and storage medium. The unit testing method includes: writing and storing corresponding test case code for development test cases; pulling the test case code and compiling it into FatJar; executing the test cases using reflection from FatJar; and storing the execution results.

Description

Technical Field

[0001] This article covers, but is not limited to, the field of testing. Background Technology

[0002] Basic components typically have very complex logic and require extensive testing to ensure quality as much as possible.

[0003] In existing technologies, developers and testers primarily use the following methods for unit testing:

[0004] (1) Writing test cases based on JUnit

[0005] JUnit is very powerful and integrates perfectly with Spring, making it the preferred choice for writing unit tests in the Java world. However, it can only be executed manually within the code and is not well managed because it's typically written within the current project. Therefore, when developing new features and pulling new code branches, test cases usually need to be rewritten. Consequently, test cases from previous versions may become unmaintained and unusable after a long time. Furthermore, new project branches generally only test the features of the current branch, resulting in incomplete overall test scenarios and difficulty in guaranteeing test quality. Since it was originally designed for functional testing, management and automation were not considered. Especially with version iterations, increasing features, and rising code complexity, unit test management becomes particularly important.

[0006] (2) Write unit tests yourself using code.

[0007] Building test cases manually through code offers greater flexibility and is suitable for simple testing scenarios. However, it becomes extremely difficult, almost impossible, for complex scenarios, especially those relying on third-party components. Therefore, its applicability is very limited, and it lacks the capabilities for management and automation. It can only be used for validating simple functions during routine development.

[0008] (3) Postman

[0009] Postman is a tool for simulating HTTP calls and also has the powerful ability to store API calls. It can also store previously executed APIs and their parameters, thus offering some management capabilities. Postman can be used to test various front-end and back-end communication functionalities. However, its use cases for basic components are relatively limited, primarily suited for front-end interaction.

[0010] The basic components iterate very quickly, so existing technologies have been unable to solve the following serious problems:

[0011] 1. Large number of unit test cases

[0012] 2. Difficulty in maintaining unit test cases

[0013] 3. Unit test cases differ between different versions.

[0014] 4. Difficulty in regression testing of basic components

[0015] 5. Unit test cases are difficult to automate.

[0016] Ensuring the quality of core components has always been a challenging task. Often, with the release of a new version, previously fixed issues reappear, or new problems emerge. Even previously written test cases may become inoperable due to version changes, making historical data untraceable. Existing technologies also lack sufficient support for UI-related testing and for behavioral or state-related tests during processes. Furthermore, the compilation into FatJar results in a lengthy loading process. Therefore, a new testing methodology is urgently needed. Summary of the Invention

[0017] The following provides an overview of various exemplary technical solutions. Some simplifications and omissions may be made in this overview to highlight and illustrate certain aspects of the various exemplary technical solutions, but this does not limit the scope of the invention. Detailed descriptions of exemplary technical solutions sufficient to allow those skilled in the art to generate and use the concepts of the present invention will be presented in subsequent sections.

[0018] To address the aforementioned technical problems, the present invention provides a unit testing method, comprising: writing and storing corresponding test case code for development test cases; retrieving the test case code and compiling it into FatJar; executing the test cases using reflection from FatJar; and storing the execution results.

[0019] Preferably, the test case code further includes at least one of the following comments: category-level comments, method-level comments.

[0020] Preferably, executing test cases via reflection in FatJar further includes: loading FatJar into the JVM using a custom classloader, and executing test cases via reflection of classes in FatJar.

[0021] Preferably, the method also includes outputting the execution result to the front end.

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

[0023] Preferably, the test case code further includes at least one of the following comments: category-level comments, method-level comments.

[0024] Preferably, the test code management module is GitLab.

[0025] Preferably, executing test cases via reflection in FatJar includes: loading FatJar into the JVM using a custom classloader, and executing test cases via reflection of classes in FatJar.

[0026] Another technical solution of the present invention provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and running thereon, wherein the processor executes the computer program to implement the steps of the method described in any of the above technical solutions.

[0027] Another technical solution of the present invention provides a computer-readable storage medium, wherein the computer program, when executed by a processor, implements the steps of the method described in any of the above technical solutions.

[0028] The technical solution of the present invention has the following main beneficial effects:

[0029] First, unit test cases can be centrally managed and maintained based on the versions of the underlying components.

[0030] Second, test case sets across different component versions can be executed in parallel and automatically.

[0031] Third, it allows you to track historical unit test cases and the problem scenarios that those test cases were meant to solve. Attached Figure Description

[0032] To better understand the various exemplary embodiments, reference can be made to the accompanying drawings, in which:

[0033] Figure 1 A flowchart illustrating the unit testing method provided in the embodiment is shown;

[0034] Figure 2 A schematic diagram of the unit test apparatus provided in the embodiment is shown.

[0035] For ease of 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 Implementation

[0036] The description and figures illustrate the principles of the invention. Therefore, it will be understood that those skilled in the art will be able to design various arrangements, which, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples cited herein are primarily intended for illustrative purposes to aid the reader in understanding the principles of the invention and the concepts provided by the inventors to deepen understanding in the field, and all examples should be considered as not being limited to such specific cited examples and conditions. Additionally, as used herein, unless otherwise indicated (e.g., “or additionally” or “or in an alternative”), the term “or” means non-exclusive or (i.e., and / or). Moreover, 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.

[0037] Definitions:

[0038] JUnit: JUnit is an open-source Java testing framework for writing and running repeatable tests. It is an instance of the xUnit unit testing framework (for the Java language). It includes the following features: 1. Assertions for testing expected results; 2. Test tools for sharing common test data; 3. Test suites for easy organization and execution of tests; 4. Graphical and text-based test runners.

[0039] GitLab is an open-source project for repository management systems. It uses Git as the code management tool and builds a web service on top of it. Installation instructions can be found on GitLab's Wiki page on GitHub.

[0040] Classloader: The Classloader is a loader used to load Java classes into the Java Virtual Machine.

[0041] FatJar is a jar file that contains all project class files and resources, as well as all dependencies.

[0042] The first embodiment provides a unit testing method, see [link to documentation]. Figure 1 The method includes:

[0043] Step S101: Write and store the corresponding test case code for the development test cases;

[0044] An application (App) contains many application programming interfaces (APIs), and each API has one or more corresponding test cases. Each development version corresponds to one test version.

[0045] You can use GitLab or other suitable code management tools (GitLab will be used as an example below) to store unit test code separately by branch. Each branch corresponds to a version release or major feature improvement. First, create a development branch, generate the corresponding test branch, write the corresponding test case code for the development test cases, and store it. Link the development branch and the test branch together. Unit test cases can be based on JUnit or other testing frameworks; JUnit will be used as an example below.

[0046] Each unit test case can have additional custom annotations, with two dimensions: annotation category level and method level.

[0047] The class level primarily describes the class author, explains the class's purpose, and its category. For example:

[0048]

[0049] The method level primarily extends some characteristics of the method itself, such as its name, the test scenario corresponding to the test case, the author, and some additional descriptions of the method (mainly used for querying, statistics, etc.). For example:

[0050]

[0051] Additional attributes are defined to specifically define the purpose, function, and outcome of test cases, mapping these attributes to test cases. Enhancing JUnit unit test attributes allows for better management of unit test cases.

[0052] Step S102: Pull the test case code and compile it into FatJar;

[0053] GitLab pulls the development branch and its corresponding test branch. JUnit unit test cases for basic components can be maintained in a separate project or as an independent module within a project. When a user wants 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 a FatJar.

[0054] Traditional JUnit only allows calling individual test cases within the development environment; it requires calling multiple test cases within a class. JUnit code can be modified to support external triggering, enabling automatic reflection to invoke and execute test cases. By modifying the source code, any test case can be executed independently from outside.

[0055] Additionally, the Maven pom.xml file must contain the FatJar packaging configuration; otherwise, test cases may not be able to be invoked by loading FatJar, as follows:

[0056]

[0057]

[0058] Instead of placing test cases in the project, they are compiled into FatJar for unified management and triggered individually. Each test case is associated with the development test, making it traceable and manageable.

[0059] Step S103: Execute test cases using reflection from FatJar;

[0060] FatJar contains all the classes. The system loads FatJar into the JVM using a custom classloader, invokes the classes within FatJar via reflection, and executes the relevant test cases.

[0061] Users can bind unit test Git addresses and project branches in the console for easier future management.

[0062] When a user needs to test a specific development version of a project, they can first select the test project, then obtain all branches of the project, and then obtain the corresponding unit test case Git address based on the project branch.

[0063] Then, the code is pulled from the Git remote to the local machine and compiled into FatJar. The FatJar is then stored in the local path. The reason for compiling into FatJar is that different component versions may depend on different versions of third-party packages. If the system's own jar package is used, on the one hand, the test cases may not be able to be executed due to version issues, and on the other hand, it is necessary to continuously add the required dependent jar packages, which increases the cost.

[0064] Then, FatJar is loaded into the JVM using a custom classloader. All unit tests are iterated through, and unit test information is managed and maintained based on annotations, which can be viewed from the front end. Furthermore, test cases selected from the front end can be executed via reflection.

[0065] Step S104: Store the execution result.

[0066] After the test cases are executed, the results are stored in the database and output to the front end (such as the user's end) for easy querying.

[0067] Unit test cases are managed using GitLab, with each branch of a basic component corresponding to a branch of a unit test case. JUnit is further developed, enriching the basic attributes of unit tests through custom annotations. By modifying the source code, it supports loading pre-packaged FatJar unit test collections via different classloaders. This not only achieves isolation between classes but also provides the ability to be triggered from outside, thereby enabling automated execution of test cases.

[0068] The second embodiment provides a unit test apparatus 200, see [link to previous embodiment]. Figure 2 It includes: test code writing module 201, test code management module 202, test case management module 203, and database 204.

[0069] Test code writing module 201 is configured to write corresponding test case code for development test cases;

[0070] Test code management module 202: Configured to store test case code;

[0071] An application (App) contains many application programming interfaces (APIs), and each API has one or more corresponding test cases. Each development version corresponds to one test version.

[0072] GitLab or other suitable code management tools (GitLab will be used as an example below) can be used as the test code management module 202. Unit test code can be stored separately by branch. One branch corresponds to a version release or a major feature improvement. First, a development branch is created, and a corresponding test branch is generated. Test case code is written for the development test cases and stored. The development branch and the test branch are then linked. Unit test cases can be based on JUnit or other testing frameworks. JUnit will be used as an example below.

[0073] Each unit test case can have additional custom annotations, with two dimensions: class level and method level. Class-level annotations primarily describe the class author, purpose, and scope. Method-level annotations extend the characteristics of the method itself, such as name, the test scenario corresponding to the test case, author, and additional descriptions (mainly used for querying, statistics, etc.). Additional attributes are defined to specifically define the purpose, function, and result of the test case, mapping these attributes to the test case. Enhancing JUnit unit test attributes allows for better management of unit test cases.

[0074] The test case management module 203 is configured to pull test case code from the test code management module 202, compile it into FatJar, and execute the test cases through reflection in FatJar.

[0075] Test case management module 203 is configured to pull test case code from test code management module 202. Basic component-related JUnit unit test cases can be maintained in a separate project or as an independent module within a project. When a user wants 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 a FatJar.

[0076] Traditional JUnit only allows calling individual test cases within the development environment; it requires calling multiple test cases within a class. JUnit code can be modified to support external triggering, enabling automatic reflection to invoke and execute test cases. By modifying the source code, any test case can be executed independently from outside.

[0077] Additionally, the Maven plugin's pom.xml file must contain FatJar packaging configurations; otherwise, test cases may not be able to be invoked by loading FatJar.

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

[0079] FatJar contains all the classes. The test case management module 203 loads FatJar into the JVM using a custom classloader, invokes the classes in FatJar via reflection, and executes the relevant test cases.

[0080] Users can bind unit test Git addresses and project branches in the console for easier future management.

[0081] When a user needs to test a specific development version of a project, they can first select the test project, then obtain all branches of the project, and then obtain the corresponding unit test case Git address based on the project branch.

[0082] Then, the code is pulled from the Git remote to the local machine and compiled into FatJar. The FatJar is then stored in the local path. The reason for compiling into FatJar is that different component versions may depend on different versions of third-party packages. If the system's own jar package is used, on the one hand, the test cases may not be able to be executed due to version issues, and on the other hand, it is necessary to continuously add the required dependent jar packages, which increases the cost.

[0083] Then, FatJar is loaded into the JVM using a custom classloader. All unit tests are iterated through, and unit test information is managed and maintained based on annotations, which can be viewed from the front end. Furthermore, test cases selected from the front end can be executed via reflection.

[0084] Database 204, storing execution results.

[0085] After the test cases are executed, the results are stored in the database as 204 and output to the front end for easy querying.

[0086] A third embodiment also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and running thereon. When the processor executes the computer program, it implements the steps of any of the methods described in the above embodiments, such as steps S101 to S104; or when the processor executes the computer program, it implements the functions of each module / unit in the above embodiments, such as the functions of units 201 to 204. The computer program can 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 can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0087] The electronic device can be a mobile terminal such as a smartphone, or a computing device such as a desktop computer, laptop, PDA, or cloud server. The electronic device may include, but is not limited to, a processor and memory, and may include more or fewer components, or a combination of certain components. For example, the electronic device may also include input / output devices, network access devices, buses, etc. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor. The memory may be an internal storage unit of the electronic device, such as a hard drive or RAM. The memory may also be an external storage device of the electronic device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, FlashCard, etc. Furthermore, the memory may include both internal storage units of the electronic device and external storage devices.

[0088] The fifth embodiment also provides a computer-readable storage medium, wherein the computer program, when executed by a processor, implements the steps of the methods of any of the above embodiments.

[0089] In the various embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units can be implemented in hardware or as software functional units. If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0090] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0091] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail or in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

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

[0093] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method of unit testing, characterized by, Comprise: For the development of test case code and storage, using GitLab branch separately stored unit test code, a branch corresponds to a version release or a large feature improvement first build a development branch, the corresponding test branch, for the development of test case code and storage, the development branch and test branch are associated, each unit test case can add custom annotations, including classification level and method level, and define additional attributes, can define the purpose, use and result of test case, map the attributes to test case, enhance Junit unit test attributes; Pull the test case code and compile it into FatJar, GitLab pulls the development branch and the corresponding test branch, modifies the Junit code to support external trigger calls, and enables automatic reflection calls and test case execution; When the user needs to test a certain development version of the project, first select the test project, then get all the branches of the project, get the corresponding unit test case git address according to the project branch, pull the code from the git remote to the local after compiling it into FatJar, and store it in the local path, execute the test case through the reflection of FatJar, load FatJar into jvm through custom classloader, traverse all unit tests according to custom annotations to maintain unit test information management, and can be viewed from the front end, execute the test case through the reflection of the class in FatJar; Store the execution result, store the execution result in the database after executing the test case, and output to the front end, manage the unit test case according to GitLab, and agree that each branch of the basic component corresponds to a branch of the unit test case; Develop Junit again, enrich the basic attributes of unit test through custom annotations, and support loading the unit test collection packaged into FatJar through different classloaders by modifying the source code.

2. The method of claim 1, wherein, The test case code further comprises at least one of the following annotations: classification level annotation, method level annotation.

3. The method of claim 1, wherein, Further comprising outputting the execution result to the front end.

4. A unit testing apparatus characterized by comprising: Comprise: A test code writing module configured to write corresponding test case code for development cases; A test code management module configured to store test case code, using GitLab branch separately stored unit test code, a branch corresponds to a version release or a large feature improvement first build a development branch, produce corresponding test branch, for the development of test case code and storage, the development branch and test branch are associated, each unit test case can add custom annotations, including classification level and method level, and define additional attributes, can define the purpose, use and result of test case, map the attributes to test case, enhance Junit unit test attributes; The test case management module is configured to pull test case code from the test code management module, compile into FatJar, pull the development branch and the corresponding test branch by GitLab, modify the Junit code to support external trigger calling, enable automatic reflection calling and execute the test case, when a user needs to test a certain development version of a project, first select the test project, then obtain all branches of the project, obtain the corresponding unit test case git address according to the project branch, pull the code from the git remote to the local after compiling into FatJar, and store the FatJar in the local path, execute the test case by the reflection of FatJar, load the FatJar into the jvm through the custom classloader, traverse all unit tests according to the custom annotation to maintain the unit test information management, and can be viewed from the front end, and execute the test case by the reflection of the class in the FatJar. The database is configured to store the execution result, store the execution result in the database after executing the test case, and output to the front end, manage the unit test case according to GitLab, agree that the branch of each basic component corresponds to a unit test case branch, develop Junit again, enrich the basic properties of the unit test through the custom annotation, and support loading the unit test set packaged into FatJar through different classloaders by modifying the source code.

5. The unit testing apparatus of claim 4, wherein, The test case code further comprises at least one of the following annotations: a classification level annotation and a method level annotation.

6. The unit testing apparatus of claim 4, wherein, The test code management module is GitLab.

7. An electronic device, comprising: It comprises: A processor, a memory and a computer program stored on the memory, wherein the processor implements the method of any one of claims 1-3 when executing the computer program.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method of any one of claims 1-3.

Images