Unit test method and system
Through the real-time generation and automatic generation of simulation modules, the problems of high cost and difficult to guarantee in existing unit testing technologies are solved, and more efficient and accurate unit testing is achieved.
Patent Information
- Application Number
- CN202411639186.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-15
- Publication Date
- 2025-03-11
AI Technical Summary
Existing unit testing techniques are costly and difficult to guarantee quality, especially when other simulation modules or public simulation libraries are called internally by the module to be tested, developers need to manually create and set up a large number of simulation modules, resulting in a large amount of workload and dependent on the developer's understanding.
Through static code analysis and the running environment of the module to be tested, the simulation module is generated in real time, the signals of the module to be tested are automatically monitored and the results of the simulation module are automatically generated based on the boundary value method, reducing the work of developers to manually create simulation modules.
Reduces the workload of developers to manually create and set up simulation modules, reduces repetitive operations, and improves the quality and efficiency of unit tests.
Smart Images
Figure CN119597649A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of unit testing technology, and in particular to a unit testing method and system. Background Art
[0002] When developers write unit tests to test a module under test, they usually preset the input and output of the module under test, then run the module under test, and finally check whether the running results of the module under test meet expectations.
[0003] Within the module to be tested, other modules may be called to complete certain complex functions, which will affect the test results of the module to be tested. The existing technical solutions mainly simulate the functions of the called modules, which requires developers to create simulated functions, methods or classes of the called modules when writing unit tests, and set the responses of the simulated modules according to the code logic of the module to be tested.
[0004] In addition, there are some other technologies including simulation of specific middleware, such as the simulation library mongomock for the database link middleware mongo, the simulation request_mock for the network link middleware requests in Python language, and the simulation pytest_minio_mock for the middleware minio of the file repository MinIO.
[0005] The disadvantages of the existing technology are mainly high cost and the quality of unit testing cannot be guaranteed. The following are the technical disadvantages in two cases:
[0006] Case 1: When the module under test calls other simulation modules developed by the developer, when the developer writes the unit test, in order to more comprehensively cover the module under test, it is necessary to fully simulate the called module and manually set all possible outputs of the called simulation module, including abnormal results. The workload of writing such simulation and setting is very large, and it is heavily dependent on the developer's understanding of the module under test and the simulated module, which may seriously affect the quality of the unit test.
[0007] Case 2: When the module under test calls some public simulation libraries, developers need to link the entire simulation library to the database when writing unit tests, and still need to manually set the calling relationship of the called simulation library. In addition to being limited by the adaptability and usage restrictions of the functional modules of the public simulation library, such tests also require developers to have sufficient understanding of the simulation library. Incorrect settings or too few possible results will also affect the quality of unit tests. Summary of the invention
[0008] In view of the above problems, the object of the present invention is to provide a unit testing method and system, which can generate simulation modules in real time, and generate simulation modules in real time through static code analysis and the operating environment of the module to be tested, without the need for developers to manually create simulation modules before running unit tests. The results of the simulation modules are automatically generated by monitoring the signals of the module to be tested, and the execution path of the expected module to be tested is set before running the unit test. The present invention automatically monitors the set signals and automatically generates the results of the simulation modules based on the boundary value method, etc.
[0009] The above-mentioned object of the present invention is achieved through the following technical solutions:
[0010] A unit testing method comprises the following steps:
[0011] S1: Start the unit test environment of the module to be tested, set the startup parameters of the module to be tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module to be tested, and automatically detect all the simulation modules to be called on the paths to be executed, and exclude the simulation modules that do not have a calling relationship;
[0012] S2: for each group of the input parameters of the module to be tested, setting the expected identification of the simulation module under the current group of the input parameters, and analyzing the syntax tree of each path to be executed and saving it to the memory;
[0013] S3: Run the module to be tested. During the operation, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module to be tested, directly call and execute the simulation module that has been analyzed and automatically generated; for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module to be tested, load the simulation module in real time, start the simulation module, analyze and automatically generate the simulation module, and call and execute the simulation module;
[0014] S4: Obtaining simulation test results of the module to be tested.
[0015] Furthermore, in step S1, all the simulation modules to be called on the to-be-executed paths are automatically detected, and the simulation modules without calling relationships are excluded, specifically:
[0016] Automatically detect the simulation modules to be called on all the paths to be executed;
[0017] For the simulation module that can determine a unique execution path and call relationship during the startup phase of the module to be tested, synchronously load and start the simulation module during the unit test startup phase;
[0018] For the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, the simulation module is not loaded during the unit test startup phase. Subsequently, when the unit test is executed and needs to call the simulation module, the simulation module is loaded, started, and executed in real time.
[0019] Further, in step S2, the syntax tree of each of the paths to be executed is analyzed and saved in the memory, specifically:
[0020] The source code of the module to be tested is analyzed based on a static code analysis tool, and the calling of the external simulation module in the module to be tested, the receiving of the return value of the simulation module call, and the context of the calling statement are extracted and saved into the content.
[0021] Further, in step S3, analyzing the simulation module specifically includes:
[0022] Searching a module library based on the name of the simulation module to determine whether there is an open source simulation module in the module library;
[0023] If it exists, set the open source simulation library flag and end;
[0024] Otherwise, the source code of the simulation module is analyzed based on the static analysis tool and all interfaces and return values of the current simulation module are set, the analysis results are saved in the memory, and the automatic generation of the simulation library identifier is set.
[0025] Furthermore, in step S3, the simulation module is automatically generated, specifically including:
[0026] Loading the expected identification of the simulation module;
[0027] Loading the analysis result of the syntax tree of the to-be-executed path of the module to be tested;
[0028] Loading the simulation library;
[0029] Based on the interface and return value set when analyzing the simulation module, and the analysis result of the syntax tree of the module to be tested, a context for simulating the simulation module in the module to be tested is automatically created, and the return value of the function called by the simulation module is automatically set.
[0030] Furthermore, the return value of the simulation module calling function is automatically set using the boundary value method, specifically:
[0031] Determine a possible boundary value range based on the interface and return value set when analyzing the simulation module and the analysis result of the syntax tree of the module to be tested;
[0032] Generate a boundary value within the boundary value range using a random number generator or a preset algorithm;
[0033] According to the generated boundary value, the return value of the simulation module calling function is set using the reflection mechanism of the programming language or directly calling the interface method of the simulation module.
[0034] Further, in step S3, for the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, the simulation module is loaded in real time, started, analyzed and automatically generated, and the simulation module is called and executed, specifically:
[0035] Before running the module to be tested, for the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, calling the simulation module on the execution path to set a calling identifier;
[0036] During the running of the module to be tested, when the calling identifier is executed, the execution is suspended, the real-time simulation is triggered, the simulation module is loaded in real time, the simulation module is started, and the simulation module is analyzed and automatically generated;
[0037] The operation is resumed at the place where the module to be tested is suspended, the simulation module is called and executed, and the module to be tested is continued to be executed.
[0038] A unit testing system for executing the unit testing method as described above, comprising:
[0039] The module-to-be-tested startup module is used to start the unit test environment of the module-to-be-tested, set the startup parameters of the module-to-be-tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module-to-be-tested, and automatically detect the simulation modules to be called on all the paths to be executed, and exclude the simulation modules that do not have a calling relationship;
[0040] Prepare a data setting module, which is used to set the expected identification of the simulation module under the current group of input parameters for each group of the input parameters of the module to be tested, and analyze the syntax tree of each path to be executed and save it to the memory;
[0041] The module-to-be-tested running module is used to run the module-to-be-tested. During the running, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module-to-be-tested, the simulation module that has been analyzed and automatically generated is directly called and executed. Meanwhile, for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module-to-be-tested, the simulation module is loaded in real time, started, analyzed and automatically generated, and called and executed;
[0042] The running result verification module is used to obtain the simulation test result of the module to be tested.
[0043] A computer device comprises a memory and one or more processors, wherein the memory stores computer codes, and when the computer codes are executed by the one or more processors, the one or more processors execute the above method.
[0044] A computer-readable storage medium stores computer codes. When the computer codes are executed, the above method is executed.
[0045] Compared with the prior art, the present invention has the following beneficial effects:
[0046] A unit test method is provided, comprising the following steps: S1: starting the unit test environment of the module to be tested, setting the start-up parameters of the module to be tested, and setting at least one group of input parameters for all the paths to be executed according to all the paths to be executed of the module to be tested, and automatically detecting the simulation modules to be called on all the paths to be executed, and excluding the simulation modules that do not have a calling relationship; S2: for each group of the input parameters of the module to be tested, setting the expected identification of the simulation module under the current group of input parameters, and analyzing the syntax tree of each path to be executed and saving it to the memory; S3: running the module to be tested, during which, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module to be tested, directly calling and executing the simulation module that has been analyzed and automatically generated; for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module to be tested, loading the simulation module in real time, starting the simulation module, analyzing and automatically generating the simulation module, and calling and executing the simulation module; S4: obtaining the simulation test result of the module to be tested. The above technical solution can reduce the need for developers to manually create a large number of simulation module objects, reduce the need for developers to frequently and repeatedly set the results of simulation module call functions, and reduce the requirement for developers to have sufficient understanding of external simulation modules. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] Figure 1 This is an overall flow chart of a unit testing method of the present invention;
[0048] Figure 2 A detailed flow chart of a unit testing method of the present invention;
[0049] Figure 3 A flow chart of the analysis simulation module of the present invention;
[0050] Figure 4 A flow chart for automatically generating a simulation module for the present invention;
[0051] Figure 5 This is an overall structural diagram of a unit testing system of the present invention. DETAILED DESCRIPTION
[0052] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0053] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.
[0054] The technical terms involved in the present invention include:
[0055] (1) Unit Testing
[0056] Unit testing is a very important part of the software development process. It focuses on testing the smallest testable unit in the software, usually a function or method. Its purpose is to ensure that these independent units can correctly perform their expected functions in various situations.
[0057] When performing unit testing, developers write test cases that typically call the unit being tested and verify that its output is as expected. For example, for a function that calculates the sum of two numbers, a unit test might pass in different combinations of values and verify that the function returns the correct result.
[0058] (2) Simulation test
[0059] Mock testing plays an important role in software testing, especially when the tested function or method depends on external resources.
[0060] In actual software development, a function may call other functions, access a database, call external APIs, etc. These dependencies may complicate testing because the behavior of external resources may be unpredictable or difficult to simulate in a test environment. Mock testing solves this problem by creating mock objects.
[0061] Mock objects can simulate the behavior of external resources so that the function under test can be tested in a controlled environment. For example, if a function needs to access a database, we can create a mock database object that can return preset results without actually connecting to the database.
[0062] (3) Boundary testing
[0063] Boundary testing is a highly targeted testing method that focuses on the boundary conditions of input values or conditions.
[0064] In software, many errors often occur under boundary conditions. For example, for a function that accepts integer input, boundary conditions may include maximum value, minimum value, zero value, etc. Null value is also a common boundary condition, especially when the function accepts string or object as input.
[0065] When doing boundary testing, you need to carefully consider various edge cases and write test cases to verify the correctness of the code in these cases. For example, for a function that verifies the user's age, boundary testing may include testing for age 0, the minimum legal age, the maximum legal age, and values outside the legal range.
[0066] First embodiment
[0067] like Figure 1 and Figure 2 As shown, this embodiment provides a unit testing method, comprising the following steps:
[0068] S1: Start the unit test environment of the module to be tested, set the startup parameters of the module to be tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module to be tested, and automatically detect all the simulation modules to be called on the paths to be executed, and exclude the simulation modules that do not have a calling relationship.
[0069] In this embodiment, before starting to execute the unit test of the module to be tested, it is first necessary to start the unit test environment of the module to be tested, set the startup parameters of the module to be tested, and set input parameters for all the paths to be executed according to all the paths to be executed of the module to be tested extracted in advance. It should be noted that the set input parameters can be multiple groups of parameters, that is, a group of parameters can be set for each path to be executed. Of course, only one group of input parameters can be set, that is, all the paths to be executed can share one group of input parameters.
[0070] The startup parameters are the parameters used to start the module under test, which determine the initial state and environment of the module under test. Ensure that the module under test can start normally and enter a testable state. For example, it may include some configuration information, initialization settings, etc. These parameters may affect the overall operation mode and behavior of the module under test.
[0071] Input parameters: are parameters set after the module under test is started in order to test its different functional code paths. These parameters are received and processed by the module during its operation to trigger different functional logics. By setting multiple sets of different input parameters, the module under test can execute different code paths, thereby comprehensively testing various functions in the module. Input parameters focus more on triggering specific functional logic inside the module to verify the correctness and stability of the module under different circumstances.
[0072] In general, startup parameters are mainly used to start the module to be tested and establish a basic operating environment, while input parameters are specific data provided during the module operation process in order to fully test the module functions.
[0073] In addition, in step S1, the simulation modules to be called on all the paths to be executed are automatically detected, and the simulation modules without calling relationships are excluded, specifically:
[0074] Automatically detect the simulation modules to be called on all the paths to be executed, and process the detected simulation modules that may be called in the following two situations:
[0075] (1) For the simulation module that can determine a unique execution path and call relationship during the startup phase of the module to be tested, the simulation module is synchronously loaded and started during the unit test startup phase.
[0076] (2) For the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, the simulation module is not loaded during the unit test startup phase. Later, when the unit test is executed and needs to call the simulation module, the simulation module is loaded, started, and executed in real time.
[0077] S2: For each group of the input parameters of the module to be tested, the expected identification of the simulation module under the current group of the input parameters is set, and at the same time, the syntax tree of each path to be executed is analyzed and saved in the memory.
[0078] In step S2, for each group of input parameters of the module to be tested, it is necessary to set the expected identification of all external simulation modules called under the current group of input parameters, so as to complete the code path that the module to be tested can run under this condition. This expected identification can be understood as an expected description of the behavior or output that the simulation module should have under specific conditions. For example, if the module to be tested should call an external module under a certain group of input parameters and expect to obtain a specific return value or trigger a specific behavior, then this expected return value or behavior description can be used as the expected identification of the module to be simulated. It provides a clear goal and standard for the test process, so as to determine whether the module to be tested is running correctly when interacting with the simulation module. For example, it is expected that the return value of the simulation module called externally in the module to be tested is 1, or the return value is 2, which is determined by the expected identification here.
[0079] In addition, in step S2, the syntax tree of each of the paths to be executed is analyzed and saved into the memory, specifically: the source code of the module to be tested is analyzed based on a static code analysis tool, and the call to the external simulation module in the module to be tested, the reception of the return value of the call to the simulation module, and the context of the call statement are extracted and saved into the content.
[0080] The syntax tree of each of the paths to be executed is analyzed and saved in memory. The specific technical solution of the execution process may be the following solution:
[0081] 1. Choose a static code analysis tool
[0082] First, you need to choose a suitable static code analysis tool. Common static code analysis tools include SonarQube, Checkstyle, PMD, etc. These tools can analyze source code in multiple programming languages and detect potential problems in the code, irregular coding styles, and some security vulnerabilities.
[0083] In addition, for Python language, Pylint is also a very popular static code analysis tool. It focuses on analyzing Python code and can check many problems in the code, such as unused variables, function definition errors, and coding habits that do not conform to Python style. For example, when using Pylint to analyze a simple Python code, it will point out the situation of unused variables, reminding developers to optimize the code and avoid unnecessary variable declarations that occupy memory.
[0084] 2. Scan the source code of the module to be tested
[0085] 1. Parsing source code
[0086] The tool reads the source code file of the module under test and parses it into an internal data structure for subsequent analysis. For example, for Java code, it may be parsed into the form of an abstract syntax tree (AST).
[0087] During this process, various elements in the code will be identified, such as classes, methods, variables, statements, etc.
[0088] For Python code, when using tools such as Pylint, the code will also be parsed. It will identify elements such as function definitions, variable declarations, and various statements in the code.
[0089] 2. Identify external module calls
[0090] By analyzing the method calls, object creation and other statements in the code, determine the calls made by the module under test to other external modules.
[0091] These calls can be identified based on specific programming language syntax rules. For example, in Java, the reference to an external package can be determined by the "import" statement, and the object type of the method call can determine whether the method of the external module is called.
[0092] In Python, it is very common to introduce external modules through the "import" statement. For example, when analyzing, the analysis tool can identify the call to the external module through the "import" statement, and pay attention to the relevant situations involving the module call in the subsequent analysis.
[0093] 3. Receiving the return value of the identification module call
[0094] While analyzing the code, look for variables or statements that receive return values from external module calls.
[0095] For example, in Java, if a method call assigns the return value to a variable or uses the return value directly in an expression, the reception of the return value can be recognized.
[0096] Likewise in Python, profiling tools can identify exactly where return values from module calls are received.
[0097] 4. Determine the context of the call statement
[0098] Analyze the code surrounding the call statement to determine the context of the call.
[0099] This includes considering the method, statement, control flow, etc. of the call. For example, if an external module call is in a conditional statement, then the condition is part of the context of the call.
[0100] In Python, the analysis tool determines the context of the call statement during analysis. This context information is very important for fully understanding the running logic of the code and possible problems.
[0101] 3. Save the analysis results to memory
[0102] 1. Data structure design
[0103] Design a suitable data structure to store the analysis results. This may be a data object with multiple fields, or a large complex data structure such as a hash table, tree, etc., depending on the complexity of the analysis results and the needs of subsequent use.
[0104] For example, for Python code analysis results, a data structure might be designed to store information about function calls, variable usage, external module calls, and so on.
[0105] 2. Stored Procedures
[0106] The identified information such as external module calls, return value reception, and call statement context is stored in memory according to the designed data structure.
[0107] You can use the memory management mechanism provided by the programming language, such as using objects and collection classes in Java to store data.
[0108] In Python, you can also use built-in data structures and objects such as dictionaries and lists to store analysis results.
[0109] S3: Run the module to be tested. During the operation, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module to be tested, directly call and execute the simulation module that has been analyzed and automatically generated; for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module to be tested, load the simulation module in real time, start the simulation module, analyze and automatically generate the simulation module, and call and execute the simulation module.
[0110] Specifically, in step S3, in the process of running the module to be tested, it is also necessary to run the simulation module in two cases:
[0111] One is that the simulation module that has determined the unique execution path and call relationship during the startup phase of the module to be tested directly calls and executes the simulation module that has been analyzed and automatically generated. It should be noted that this solution completes the analysis and automatic generation of the simulation module before the module to be tested runs, which can reduce the pressure on the server during the running phase.
[0112] The other is that the simulation module cannot determine the unique execution path and call relationship during the startup phase of the module to be tested, and it is necessary to load the simulation module in real time, start the simulation module, analyze and automatically generate the simulation module, and call and execute the simulation module. It should be noted that the analysis and automatic generation of the simulation module in this solution can only be performed in the running phase because the unique execution path cannot be determined during the startup phase.
[0113] However, the analysis of the simulation module and the automatically generated solutions of the above two solutions are the same whether they are performed before or during operation. The following is an explanation of the specific analysis and automatic generation of the simulation module:
[0114] A: Analyze the simulation module, such as Figure 3 As shown, specifically including:
[0115] Based on the name of the simulation module, the module library is searched to determine whether there is an open source simulation module in the module library; if so, the open source simulation library identifier is set and the process ends; otherwise, the source code of the simulation module is analyzed based on a static analysis tool and all interfaces and return values of the current simulation module are set, the analysis results are saved in the memory, and the automatically generated simulation library identifier is set and used.
[0116] Specific plans may be:
[0117] 1. Search for installed open source simulation modules
[0118] 1. Get the module name
[0119] Extract the name of the module to be simulated from the current test process. This name is usually determined when designing test cases or configuring the test environment.
[0120] 2. Traverse the unit test running environment
[0121] Check various dependent libraries, plug-ins, or installed tool collections in the unit test running environment to see if there is an open source simulation module that matches the name of the module to be simulated.
[0122] This can be done by querying your environment's dependency management system (such as Maven or npm's dependency list), inspecting specific test tool configuration files, or using the module lookup mechanism provided by your programming language.
[0123] For Python, we can do this in the environment of its commonly used dependency management tool PIP. For example, suppose we want to test a function involving data processing, which may use a module to be simulated for simulated data generation. We first determine the name of this module to be simulated, such as "mock_data_generator". Then we can use PIP's related commands or the API it provides to traverse the list of installed libraries to see if there is an open source simulation module that matches the name "mock_data_generator".
[0124] 3. Identify open source simulation modules
[0125] If a module is found during the traversal process, whose name matches the name of the module to be simulated or has a similar functional description, it is considered to be a possible open source simulation module.
[0126] Further check the module's documentation, metadata, or code comments to confirm whether it can indeed be used to simulate the behavior of the module to be simulated.
[0127] Taking the search for "mock_data_generator" in the Python environment as an example, if we find a module called "similar_mock_data_generator" through PIP traversal, and its name is similar to what we are looking for, we need to further check its documentation to see if it can really simulate the data generation function we need, such as whether it can generate different types of data samples according to the rules we expect.
[0128] 4. Set the open source simulation library logo
[0129] If you are sure that you have found a suitable open source simulation module, set a specific identifier so that the subsequent testing process knows that this open source module can be used.
[0130] This identifier can be a global variable, a setting in a configuration file, or a flag stored in memory.
[0131] In Python, we can set a global variable in the test script, such as "using_open_source_mock_lib = True" to indicate that a suitable open source mock module has been found and is ready to be used. Or we can add a setting item in the configuration file (such as the common ".ini" format configuration file), such as adding "use_open_source_mock_lib = True" under the "[MockSettings]" section to mark this situation.
[0132] 2. Analyze and set the simulation module interface and return value (if no open source module is found)
[0133] 1. Choose a static code analysis tool
[0134] As in the previous step, choose a static code analysis tool that is suitable for analyzing source code. This tool should be able to handle the programming language used by the module to be simulated.
[0135] For Python language, Pylint, Astroid, etc. are commonly used static code analysis tools, which can help us analyze Python source code.
[0136] 2. Analyze the simulation module source code
[0137] Use static code analysis tools to read the source code file of the module to be simulated.
[0138] Identify all interface definitions in the module, including method signatures, parameter types, and return value types.
[0139] For each interface, analyze its implementation logic in the target code to determine the possible return value range or specific return value situations.
[0140] Suppose we have a mock module "custom_mock_module" written by ourselves, which contains an interface function "generate_mock_data" with a parameter type of "int" indicating the number of data to be generated. By using static code analysis tools such as Pylint, we can identify the definition of this interface and then deeply analyze its implementation logic in the code. For example, we find that it may return a list type of data according to the parameter value passed in, and the length of the list will fluctuate roughly within a certain range of the parameter value passed in, which determines its possible return value range.
[0141] 3. Set the interface and return value
[0142] Based on the analysis results, set a reasonable reward value for each interface. This can be based on some preset rules, understanding of business logic, or randomly generated values, depending on the test requirements.
[0143] You can use the reflection mechanism of the programming language or code generation tools to dynamically set the return value of the interface.
[0144] Continuing with the example of "custom_mock_module", if our test requirement is to simulate a relatively stable simulation data output, we can set a relatively fixed return value based on the implementation logic of the "generate_mock_data" interface analyzed previously. For example, when the input parameter is 5, we can use code generation tools (for example, in Python, we can use the "eval" function combined with a specific expression to generate code) to dynamically set the return value of this interface to a list containing 5 specific data elements, such as [1,2,3,4,5].
[0145] 4. Save analysis results to memory
[0146] The analyzed interface information and the set return value are stored in the memory in a suitable data structure.
[0147] You can use a hash table, object array, or custom data structure to store this information for quick access during subsequent testing.
[0148] In Python, we can use a dictionary structure to store this information. For example, for the "generate_mock_data" interface of "custom_mock_module", we can create a dictionary as follows:
[0149] {
[0150] "interface_name":"generate_mock_data",
[0151] "parameters":["int"],
[0152] "return_value":[1,2,3,4,5],
[0153] "implementation_logic":"Generate the corresponding number of data elements according to the input parameter value"
[0154] }
[0155] In this way, the relevant information of the interface and the set return value are stored in the dictionary, which is convenient for query and use in subsequent tests.
[0156] 5. Set the automatic generation of simulation library logo
[0157] After completing the analysis and setup of the simulation module, a flag is set to indicate that the automatically generated simulation library is being used.
[0158] This identifier can be used to distinguish different sources of simulation groups in a similar way to setting the open source simulation library identifier mentioned above.
[0159] In Python, you can also set a global variable, such as "using_auto_generated_mock_lib = True" to indicate that the automatically generated mock library is being used. Or add corresponding settings in the configuration file, such as adding "use_auto_generated_mock_lib = True" under the "[MockSettings]" section of the ".ini" format configuration file to mark this situation.
[0160] B: Automatically generate the simulation module, such as Figure 4 As shown, specifically including:
[0161] Load the expected identifier of the simulation module; load the analysis result of the syntax tree of the to-be-executed path of the module to be tested; load the simulation library; based on the interface and return value set when analyzing the simulation module, and the analysis result of the syntax tree of the module to be tested, automatically create a context for simulating the simulation module in the module to be tested, and automatically set the return value of the simulation module calling function.
[0162] Specific plans may be:
[0163] 1. Result identification of loading expected simulation module
[0164] 1. Determine the storage location
[0165] Specify the storage location in the system where the expected simulation module result identifier is set. This may be a specific configuration file, a database table, a variable in memory, or other storage mechanism.
[0166] 2. Read the logo
[0167] Use appropriate technical means to read this result identifier. If it is a file, you can use the file read operation; if it is a database, you can execute a query statement; if it is in memory, you can directly access the corresponding variable.
[0168] 3. Parsing logo
[0169] Parse the result identifiers read to understand their meaning and function. This may involve decoding or interpreting identifiers in a specific format to determine the expected simulation module behavior.
[0170] 2. Load the analysis results of the module to be tested
[0171] 1. Also determine the storage location
[0172] Specify where to store the results of the analysis of the module under test. This may be similar to how the result identifiers are stored, or it may be different, depending on the design of the system.
[0173] 2. Read the analysis results
[0174] Depending on the storage location, the corresponding reading method is used to obtain the analysis results. If it is stored in memory, it can be accessed through reference passing or global variables; if it is a file or database, the corresponding reading operation can be performed.
[0175] 3. Data structure conversion (if necessary)
[0176] You may need to convert the read analysis results into a specific data structure suitable for the current processing for subsequent operations. For example, convert the database query results into an object list or hash table.
[0177] 3. Loading the simulation library
[0178] 1. Identify the simulation library type
[0179] Decide whether to use an open source mock library or an automatically generated mock library. This will determine how and from where the mocks are loaded.
[0180] 2. Loading open source simulation library
[0181] If it is an open source simulation library, you may need to operate according to its specific loading mechanism. For example, if it is a Java library, you can load it by adding dependencies to the project build file (such as Maven or Gradle) and importing the corresponding package in the code.
[0182] 3. Load the automatically generated simulation library
[0183] If it is an automatically generated simulation library, you may need to read the generated code files from a specific storage location (such as a specific directory in the file system) and dynamically load these files at runtime. You can use the dynamic loading mechanism provided by the programming language, such as Java's ClassLoader.
[0184] 4. Automatically create the context of the mock module
[0185] 1. Collect relevant information
[0186] Using the results of the above steps, collect the information needed to create the mock module context. This may include the calling context of the module under test, the behavior of the expected mock module, and the interface and return value settings of the mock library.
[0187] 2. Build context object
[0188] Based on the collected information, an object representing the simulation module context is constructed. This object can contain various properties and methods to provide necessary context information during the operation of the simulation module.
[0189] 3. Initialize context
[0190] Initialize the constructed context object and set the initial state and parameters. This may include setting default values, loading configuration information, or initializing according to specific rules.
[0191] In addition, we need to use the boundary value method to automatically set the return value of the simulation module call function, specifically:
[0192] Based on the interface and return value set when analyzing the simulation module, and the analysis result of the syntax tree of the module to be tested, the possible boundary value range is determined. This can be determined by analyzing the parameter type of the interface, the restrictions of the business logic or the empirical rules.
[0193] Use a random number generator or a preset algorithm to generate a boundary value within the boundary value range. For example, if the interface parameter is an integer type and the business logic requires the return value to be between 0 and 100, a random number generator can be used to generate an integer within this range as the boundary value.
[0194] According to the generated boundary value, the reflection mechanism of the programming language or the interface method of the simulation module is used to set the return value of the simulation module calling function, ensuring that the type and format of the return value are consistent with the interface requirements.
[0195] In addition, for the second type of simulation module in which the unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, real-time loading of the simulation module, startup of the simulation module, analysis and automatic generation of the simulation module, and calling and executing the simulation module are explained in more detail. Different from the first case, some additional settings need to be made, specifically:
[0196] Before running the module to be tested, for the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, calling the simulation module on the execution path to set a calling identifier;
[0197] During the running of the module to be tested, when the calling identifier is executed, the execution is suspended, the real-time simulation is triggered, the simulation module is loaded in real time, the simulation module is started, and the simulation module is analyzed and automatically generated;
[0198] The operation is resumed at the place where the module to be tested is suspended, the simulation module is called and executed, and the module to be tested is continued to be executed.
[0199] S4: Obtain the simulation test result of the module to be tested and verify whether the operation result of the module to be tested is consistent with the expected result.
[0200] Second embodiment
[0201] like Figure 5 As shown, this embodiment provides a unit testing system for executing the unit testing method in the first embodiment, including:
[0202] The module-to-be-tested startup module 1 is used to start the unit test environment of the module-to-be-tested, set the startup parameters of the module-to-be-tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module-to-be-tested, and automatically detect all the simulation modules to be called on the paths to be executed, and exclude the simulation modules that do not have a calling relationship;
[0203] Prepare a data setting module 2, which is used to set the expected identification of the simulation module under the current group of input parameters for each group of the input parameters of the module to be tested, and analyze the syntax tree of each path to be executed and save it to the memory;
[0204] The module-to-be-tested running module 3 is used to run the module-to-be-tested. During the running, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module-to-be-tested, the simulation module that has been analyzed and automatically generated is directly called and executed. Meanwhile, for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module-to-be-tested, the simulation module is loaded in real time, started, analyzed and automatically generated, and called and executed;
[0205] The operation result verification module 4 is used to obtain the simulation test result of the module to be tested.
[0206] A computer-readable storage medium stores a computer code. When the computer code is executed, the above method is executed. A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program. The program can be stored in a computer-readable storage medium. The storage medium can include: a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.
[0207] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.
[0208] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0209] It should be noted that the above embodiments can be freely combined as needed. The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered as the protection scope of the present invention.
Claims
1. A unit testing method, characterized in that: The following steps are involved: S1: Start the unit test environment of the module to be tested, set the startup parameters of the module to be tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module to be tested, and automatically detect all the simulation modules to be called on the paths to be executed, and exclude the simulation modules that do not have a calling relationship; S2: for each group of the input parameters of the module to be tested, setting the expected identification of the simulation module under the current group of the input parameters, and analyzing the syntax tree of each path to be executed and saving it to the memory; S3: Run the module to be tested. During the operation, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module to be tested, directly call and execute the simulation module that has been analyzed and automatically generated; for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module to be tested, load the simulation module in real time, start the simulation module, analyze and automatically generate the simulation module, and call and execute the simulation module; S4: Obtaining simulation test results of the module to be tested.
2. The unit testing method according to claim 1, characterized in that: In step S1, all the simulation modules to be called on the to-be-executed paths are automatically detected, and the simulation modules without calling relationships are excluded, specifically: Automatically detect the simulation modules to be called on all the paths to be executed; For the simulation module that can determine a unique execution path and call relationship during the startup phase of the module to be tested, synchronously load and start the simulation module during the unit test startup phase; For the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, the simulation module is not loaded during the unit test startup phase. Subsequently, when the unit test is executed and needs to call the simulation module, the simulation module is loaded, started, and executed in real time.
3. The unit testing method according to claim 1, characterized in that: include: In step S2, the syntax tree of each of the paths to be executed is analyzed and saved in the memory, specifically: The source code of the module to be tested is analyzed based on a static code analysis tool, and the calling of the external simulation module in the module to be tested, the receiving of the return value of the simulation module call, and the context of the calling statement are extracted and saved into the content.
4. The unit testing method according to claim 1, characterized in that: include: In step S3, analyzing the simulation module specifically includes: Searching a module library based on the name of the simulation module to determine whether there is an open source simulation module in the module library; If it exists, set the open source simulation library flag and end; Otherwise, the source code of the simulation module is analyzed based on the static analysis tool and all interfaces and return values of the current simulation module are set, the analysis results are saved in the memory, and the automatic generation of the simulation library identifier is set.
5. The unit testing method according to claim 4, characterized in that: include: In step S3, the simulation module is automatically generated, specifically including: Loading the expected identification of the simulation module; Loading the analysis result of the syntax tree of the to-be-executed path of the module to be tested; Loading the simulation library; Based on the interface and return value set when analyzing the simulation module, and the analysis result of the syntax tree of the module to be tested, a context for simulating the simulation module in the module to be tested is automatically created, and the return value of the function called by the simulation module is automatically set.
6. The unit testing method according to claim 5, characterized in that: include: The return value of the simulation module calling function is automatically set using the boundary value method, specifically: Determine a possible boundary value range based on the interface and return value set when analyzing the simulation module and the analysis result of the syntax tree of the module to be tested; Generate a boundary value within the boundary value range using a random number generator or a preset algorithm; According to the generated boundary value, the return value of the simulation module calling function is set using the reflection mechanism of the programming language or directly calling the interface method of the simulation module.
7. The unit testing method according to claim 1, characterized in that: include: In step S3, for the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, the simulation module is loaded in real time, started, analyzed and automatically generated, and the simulation module is called and executed, specifically: Before running the module to be tested, for the simulation module whose unique execution path and calling relationship cannot be determined during the startup phase of the module to be tested, calling the simulation module on the execution path to set a calling identifier; During the running of the module to be tested, when the calling identifier is executed, the execution is suspended, the real-time simulation is triggered, the simulation module is loaded in real time, the simulation module is started, and the simulation module is analyzed and automatically generated; The operation is resumed at the place where the module to be tested is suspended, the simulation module is called and executed, and the module to be tested is continued to be executed.
8. A unit testing system for executing the unit testing method according to any one of claims 1 to 7, characterized in that: include: The module-to-be-tested startup module is used to start the unit test environment of the module-to-be-tested, set the startup parameters of the module-to-be-tested, and set at least one set of input parameters for all the paths to be executed according to all the paths to be executed of the module-to-be-tested, and automatically detect the simulation modules to be called on all the paths to be executed, and exclude the simulation modules that do not have a calling relationship; Prepare a data setting module, which is used to set the expected identification of the simulation module under the current group of input parameters for each group of the input parameters of the module to be tested, and analyze the syntax tree of each path to be executed and save it to the memory; The module-to-be-tested running module is used to run the module-to-be-tested. During the running, for the simulation module whose unique execution path and calling relationship have been determined at the startup stage of the module-to-be-tested, the simulation module that has been analyzed and automatically generated is directly called and executed. Meanwhile, for the simulation module whose unique execution path and calling relationship cannot be determined at the startup stage of the module-to-be-tested, the simulation module is loaded in real time, started, analyzed and automatically generated, and called and executed; The running result verification module is used to obtain the simulation test result of the module to be tested.
9. A computer device comprising a memory and one or more processors, wherein the memory stores computer codes, and when the computer codes are executed by the one or more processors, the one or more processors execute the method according to any one of claims 1 to 7. 10 . A computer-readable storage medium storing a computer code. When the computer code is executed, the method according to claim 1 is executed.