A software unit test function piling method

Abstract

The application discloses a software unit test function staking method, which comprises the following steps: firstly, defining a stake behavior type AuMockInfo, which comprises a stake function return value pointer, a current object this pointer, a parameter number and a parameter pointer list, and completing stake function behavior description by delivering the AuMockInfo, then unifying the stake function interface based on the AuMockInfo and defining a corresponding stake function pointer type; secondly, establishing a stake function mapping table and a stake function staking state sequence mapping table; thirdly, obtaining a plurality of called functions in a function to be tested, transforming each called function defined in a source code form, inserting AuMockInfo type variable definition and staking judgment statements at the entry of the called function; and fourthly, generating a wrapping function for each called function without a source code or provided in a library form, and inserting AuMockInfo type variable definition and staking judgment statements in the wrapping function. The application significantly improves the universality and flexibility of function staking, realizes the underlying technology independence, and can be used as an underlying method of a test framework or tool.

Description

Technical Field

[0001] This invention relates to a method for stubbing functions in software unit tests, belonging to the field of software testing technology. Background Technology

[0002] In software unit testing, function stubbing is a common technique used to simulate and control the behavior of functions in order to isolate the code under test from its dependent external components or modules within the test environment. The main purpose of stubbing is to replace actual function calls during testing, thereby providing predictable return values ​​or behaviors so that specific parts of the code can be tested without relying on external systems or complex dependencies.

[0003] During testing, a stub function is used to replace the actual function. A stub function is typically a lightweight substitute that simulates the behavior of the actual function, but its implementation is usually simpler, and its return value or behavior can be pre-defined. This allows testers to test the code under test without relying on the actual function implementation.

[0004] However, with the evolution of programming languages ​​and software architectures, function stubling technology faces new challenges. Especially in languages ​​like C++ that support object-oriented features, traditional stubling methods often struggle to handle complex language features such as namespaces, class member functions, abstract classes, and templates. Taking the automated unit and integration testing tool SunwiseAUnit as an example, its existing C language function stubling solution falls short when dealing with C++ code—it cannot effectively handle scenarios such as member function stubling, abstract class interface mocking, and dynamic instantiation of template classes or functions. This technical bottleneck severely restricts the tool's applicability in modern C++ projects, necessitating a new function stubling method that adapts to the characteristics of the C++ language to improve SunwiseAUnit's comprehensive support for C++.

[0005] Currently, there are two main methods for function stubbing: 1) Function stubbing based on binary library replacement or modification of function addresses. Patent CN202010789767 discloses a function stubbing method and apparatus. This method compiles and stores a stub function library containing stub functions and records the function addresses of the stub function library after compilation. It then loads a pseudo-shared library and a proxy program linked to the application as a dynamic library, allowing the proxy program to overload the pseudo-shared library, thereby achieving function stubbing within the application. Patent CN201510322979 discloses a method for dynamic stubbing in Linux kernel unit testing. Its kernel stubbing module obtains read and write permissions for code segments and modifies the target address of the calling instruction to the stub function address, thus achieving dynamic stubbing. The advantage of the above methods is that they can stub running programs, but they depend on specific compilers and platforms, requiring customized development for different platforms, resulting in poor applicability.

[0006] 2) Source code modification and transformation method. This method replaces stub functions by modifying and transforming them at the source code level. Common unit testing frameworks or tools such as Google Test, Testbed, and C++Test all use this method for stubding. Because it operates at the source code level, this method has good cross-platform support and multi-compiler compatibility, and possesses good versatility and portability, making it widely used in practice. Although the source code modification and transformation method of stub functions performs excellently in terms of cross-platform and compiler support, existing testing frameworks and tools still have some shortcomings in practical use: (1) For example, Google Test is written in C++, and the framework is too complex. The code introduced by the framework alone is close to 2MB, which is not suitable for embedded environments. (2) For foreign commercial tools such as C++Test and Testbed, there are licensing issues, and code changes are tied to their underlying framework, which is not conducive to integration into self-developed unit testing tools; (3) In addition, there is a need for dynamic switching of stub state in actual testing. For example, when running a test case, a function is called multiple times, and it is desired to use the stub function on some of the calls and call the real function on other cases. Existing tools usually cannot support this. Summary of the Invention

[0007] The technical problem solved by this invention is to overcome the shortcomings of the prior art and propose a software unit test function stub method. Stub determination code is inserted at the function entry point. When stub is executed, the system jumps directly to the corresponding stub function and returns the result. Otherwise, the original called function logic continues to be executed. Finally, dynamic function stub is achieved based on the result of the stub determination.

[0008] The technical solution of this invention is: A method for stubbing software unit test functions includes: Define a stub behavior type AuMockInfo, including a return value pointer, the current object's this pointer, the number of stub function parameters, and an array of parameter pointers, to fully describe the behavior of the stub function; unify the stub function interface, the return value of which contains only one parameter of type AuMockInfo, and all behaviors of the stub function are passed through this parameter; define corresponding stub function pointers, and all stub functions are called through stub function pointers. Establish a stub function mapping table and a stub function stub state sequence mapping table; wherein, the stub function mapping table records the mapping relationship between function name strings and stub function pointers, and the stub function stub state sequence mapping table records the mapping relationship between function name strings and function stub state sequences; Obtain multiple called functions from the function under test, and process each called function as follows: If the called function is defined in source code form, the called function is transformed as follows: a variable definition of type AuMockInfo is inserted at the entry point of the called function and initialized with the function return value, the current object pointer, and the parameter list; then a stubding judgment statement is inserted to determine whether stubding is performed. If stubding is performed, the execution jumps to the stub function; otherwise, the source code logic is executed. If the called function has no source code or is provided as a library, a corresponding wrapper function is generated, and the code is modified to call the wrapper function. An AuMockInfo type variable definition and a stub condition statement are inserted at the entry point of the wrapper function. If stub is found, execution jumps to the stub function; otherwise, the original called function is called.

[0009] Furthermore, the prototype of the piling determination statement is: if(AUnitDoMock(funcName,AuMockInfo )) Where funcName is the fully qualified name string of the function, and AuMockInfo is the fully qualified name string of the function. It is a pointer to a variable that represents the behavior of a stub function.

[0010] Furthermore, based on the piling determination statement, it is determined whether piling should be carried out, specifically as follows: In the stub decision statement AUnitDoMock, it first checks whether the stub function mapping table contains the name of the called function: if it does, it indicates stubling, and then obtains the stub function pointer through the stub function mapping table to call the stub function; otherwise, it does not stub, and executes the original logic of the called function. If it is determined to be stubling, further query the stub function stubling state sequence mapping table to see if the called function name is included: if it is included, it means that the called function has a stubling state switch during the call process. Obtain the corresponding stubling state sequence according to the called function name, and determine the current stubling state in combination with the current call count; if it is not included, continue to process it as stubling.

[0011] Furthermore, the method for conducting pile driving tests is as follows: To write test cases, first clear the stub function mapping table and the stub function stubging state sequence mapping table. Define stub functions in the test case script. Stub functions have no return value and only contain an AuMockInfo pointer type parameter. Simulate stub function behavior by reading and writing parameters within the stub function. Add the mapping relationship between function names and stub functions to the stub function mapping table. Next, obtain the stubging state sequence of the function from the test case data and add the mapping relationship between function names and stubging state sequences to the stub function stubging state sequence mapping table. Finally, write the test case input, call the function under test, and set the expected results. Execute the test case script to complete the test.

[0012] Furthermore, based on the predefined stub functions of each called function, the mapping relationship between the function name string and the stub function is added to the stub function mapping table.

[0013] Furthermore, based on the function stubling status and test requirements of the current test case, if the stub function has a stubling status switch, the mapping relationship between the function name string and the stubling status sequence is added to the stub function stubling status sequence mapping table.

[0014] Furthermore, if the test requires the called function to perform dynamic stubling, a stubling state sequence is defined; where, when a call needs to execute the real function, the value of this sequence is set to 0; and when a call needs to execute the stub function, the value of this sequence is set to 1.

[0015] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0016] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0017] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0018] The advantages of this invention compared to the prior art are: (1) This invention solves the problem of stub functions not being isolated between different test cases by binding the function name and stub function pointer mapping relationship in the stub function mapping table and flexibly binding different stub function logic by modifying the function pointer mapping relationship in the test cases, thereby achieving the purpose of flexible stub installation.

[0019] (2) This invention solves the problem of not being able to stub library functions by transforming code, adding wrapper functions to library functions and adding stub judgment in wrapper functions, and realizes unified stub support for source code functions and library functions.

[0020] (3) By binding the function name and the stub state sequence mapping relationship in the stub function stub state sequence mapping table and setting the stub state sequence in the script, this invention solves the problem that the stub function cannot support stubling in a few calls and not stubling in other cases when it is called multiple times in the same test case, realizes the function of dynamic switching of stub state at runtime, and meets the testing requirements of complex timing and interaction scenarios. Attached Figure Description

[0021] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart of the software unit test function stubding method of the present invention; Figure 2 This is a schematic diagram of the function to be tested in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the transformation of the defined function Calc::add according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the wrapping of the undefined function gettime in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the definition of the stub function in an embodiment of the present invention; Figure 6 A schematic diagram of test cases for embodiments of the present invention. Detailed Implementation

[0022] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0023] This invention proposes a method for stubbing software unit test functions, such as... Figure 1 As shown, it includes: S1: Define a stub behavior type to describe the behavior of stub functions. All behaviors of stub functions (return values, object pointers, and parameter lists, etc.) are passed through this type. Further define a stub function pointer to call the stub function. Establish a stub function mapping table and a stub function stubding state sequence mapping table. The stub function mapping table records the mapping relationship between function names and corresponding stub functions (referenced through stub function pointers); the stub function stubding state sequence table records the mapping relationship between function names and function stubding state sequences.

[0024] S2: Transform the function.

[0025] S3: For functions defined in source code form, insert a stub conditional statement at the function entry point. If the condition is not to stub, execute the original logic of the function directly; otherwise, call the stub function and return.

[0026] S4: For functions that are undefined or defined as libraries, create corresponding wrapper functions and modify the statements that call the original function to call the wrapper function. Then, insert a stubding condition at the entry point of the wrapper function. If it is determined that no stub is needed, call the original function directly and return; otherwise, call the stub function and return.

[0027] Specifically, in steps S3 and S4, when determining function stubling, the system first checks whether the function is included in the stub function mapping table. If it is included, stubling is performed, and the stub function pointer can be obtained from the stub function mapping table to call the stub function later; otherwise, stubling is not performed. If stubling is performed, the system also checks whether the function is included in the stubling state sequence mapping table. If it is included, it indicates that there is a stubling state switch during the call process. Then, the sequence is obtained from the stubling state sequence mapping table based on the function name, and the stubling state is determined based on the sequence and the current call count; otherwise, stubling is performed continuously.

[0028] In the test script, first, write custom stub functions, then add the mapping between function names and stub functions to the stub function mapping table. If there are stub function stub state transitions, the mapping between function names and stub sequences also needs to be added to the stub state sequence mapping table. Finally, write the test case input, call the function under test, and set the expected results to complete the test case writing.

[0029] During test case execution, when a function is executed, the system determines whether to perform stubbing or make an actual call based on the stubbed function, thus achieving flexible function stubbing functionality.

[0030] The method proposed in this invention will be further illustrated below through examples: Taking a C++ program as an example, such as Figure 2As shown, ut is the function under test, which calls the functions Calc::add and gettime. The Calc::add function is defined, while gettime is a library function that is only declared. In the test case, Calc::add and gettime are stubbed, and the first call to Calc::add is the actual call, while the second call is a stub.

[0031] 1) Establish a stub function mapping table (map1) and a stub function stub state sequence mapping table (map2). map1 records the mapping relationship between function name strings and corresponding stub function pointers, and map2 records the mapping relationship between function name strings and function stub state sequences.

[0032] 2) Define the stub behavior type AuMockInfo to describe the behavior of the stub function, including the return address, the current object pointer, the number of stub function parameters, and the pointer array of stub function parameters, so that the behavior of the stub function can be described by passing AuMockInfo; then, on this basis, define the stub function pointer type AUnitFuncMock_FP, whose parameter is the AuMockInfo pointer.

[0033] 3) For a defined function Calc::add, perform a transformation. At the beginning of the function, define an AuMockInfo type variable mock to store the return value, object pointer, and parameter list of Calc::add, etc., and then insert the prototype as if(AUnitDoMock(funcName,AuMockInfo) The staking condition statement in )) is where funcName is the fully qualified function name string, such as "Calc::add(int,int)" and AuMockInfo. A pointer to a variable representing the behavior of a stub function, such as "&mock". If it's determined that no stub is needed, the original logic of the called function is executed directly; otherwise, the stub function is called and returned. Example code is shown below. Figure 3 As shown.

[0034] 4) For the library function `gettime`, which is a library function without source code in the tested code, the tool defines a corresponding wrapper function `AU_C_gettime`, whose type is exactly the same as `gettime`. Similarly, after defining the `AuMockInfo` variable at the beginning of the wrapper function, stub-based conditional code is inserted; then, the statement calling `gettime` is modified to call the wrapper function `AU_C_gettime`, as shown in the example code. Figure 4 As shown.

[0035] 5) In the stubling decision statement AUnitDoMock, first check if map1 contains funcName. If it does not, it means no stubling, and directly returns 0 before executing the actual function logic. If it does, then check if map2 contains funcName. If it does not, it means stubling has occurred and there is no state transition. Directly call the stub function through the function pointer obtained from map1 and return. If it does, then obtain the stubling state sequence from map2. Based on the current number of calls and the state of the corresponding index in the sequence: in the no-stubling state, directly return 0 and execute the actual function logic; in the stubling state, call the stub function through the function pointer obtained from map1 and return.

[0036] 6) In the test case script, define stub functions `my_stub_calc` and `my_stub_gettime`. The addresses of function parameters, member variables, and return values ​​can be obtained through `AuMockInfo`. After casting to pointers of the corresponding types, read and write operations can be performed. Example code is shown below. Figure 5 As shown.

[0037] 7) In the test case script, write the test cases. First, clear map1 and map2 to eliminate the influence of stub states from other test cases. Then, based on the function stub state of the current test case, add a stub state mapping table and a stub state sequence to map1 and map2. According to the test requirements of this case, dynamically stub Calc::add. The first call executes the real function, and the second call stubs the function. Therefore, the sequence {0,1} is defined and recorded in map2. Example code is as follows: Figure 6 As shown.

[0038] 8) Following the steps above, set the stub status for map1 and map2 in the test case. When the test case is executed and reaches the Calc::add and gettime functions, the stub status can be determined by map1, map2 and the stub determination in the function, thus realizing the flexible function stub function.

[0039] This method addresses the shortcomings of existing stubbing frameworks in supporting embedded environments, the licensing and exclusivity issues of commercial tools, and the lack of support for dynamic stubbing. It is applicable to various programming languages, development environments, and operating systems, and supports dynamic switching of stubbing states during operation, further improving the flexibility of testing. It can be widely applied to various software development and testing scenarios, meeting the requirements for dynamic adjustment and on-demand stubbing for different testing needs.

[0040] The embodiments described above are merely preferred embodiments of the present invention. Ordinary variations and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for stubbing software unit test functions, characterized in that, include: Define a stub behavior type AuMockInfo, including a return value pointer, the current object's this pointer, the number of stub function parameters, and an array of parameter pointers, to fully describe the behavior of the stub function; unify the stub function interface, the return value of which contains only one parameter of type AuMockInfo, and all behaviors of the stub function are passed through this parameter; define corresponding stub function pointers, and all stub functions are called through stub function pointers. Establish a stub function mapping table and a stub function stub state sequence mapping table; wherein, the stub function mapping table records the mapping relationship between function name strings and stub function pointers, and the stub function stub state sequence mapping table records the mapping relationship between function name strings and function stub state sequences; Obtain multiple called functions from the function under test, and process each called function as follows: If the called function is defined in source code form, the called function is transformed as follows: a variable definition of type AuMockInfo is inserted at the entry point of the called function and initialized with the function return value, the current object pointer, and the parameter list; then a stubding judgment statement is inserted to determine whether stubding is performed. If stubding is performed, the execution jumps to the stub function; otherwise, the source code logic is executed. If the called function has no source code or is provided as a library, a corresponding wrapper function is generated, and the code is modified to call the wrapper function. An AuMockInfo type variable definition and a stub condition statement are inserted at the entry point of the wrapper function. If stub is found, execution jumps to the stub function; otherwise, the original called function is called.

2. The software unit test function stubping method according to claim 1, characterized in that, The prototype of the piling decision statement is if(AUnitDoMock(funcName,AuMockInfo) ), where funcName is the fully qualified name string of the function, and AuMockInfo It is a pointer to a variable that represents the behavior of a stub function.

3. The software unit test function stubping method according to claim 2, characterized in that, The determination of whether to drive piles is based on the pile driving judgment statement, specifically as follows: In the stub decision statement AUnitDoMock, it first checks whether the stub function mapping table contains the name of the called function: if it does, it indicates stubling, and then obtains the stub function pointer through the stub function mapping table to call the stub function; otherwise, it does not stub, and executes the original logic of the called function. If it is determined to be stubling, further query the stub function stubling state sequence mapping table to see if the called function name is included: if it is included, it means that the called function has a stubling state switch during the call process. Obtain the corresponding stubling state sequence according to the called function name, and determine the current stubling state in combination with the current call count; if it is not included, continue to process it as stubling.

4. The software unit test function stubping method according to claim 1, characterized in that, The method for conducting pile driving tests is as follows: To write test cases, first clear the stub function mapping table and the stub function stubging state sequence mapping table. Define stub functions in the test case script. Stub functions have no return value and only contain an AuMockInfo pointer type parameter. Simulate stub function behavior by reading and writing parameters within the stub function. Add the mapping relationship between function names and stub functions to the stub function mapping table. Next, obtain the stubging state sequence of the function from the test case data and add the mapping relationship between function names and stubging state sequences to the stub function stubging state sequence mapping table. Finally, write the test case input, call the function under test, and set the expected results. Execute the test case script to complete the test.

5. A method for stubbing software unit test functions according to claim 4, characterized in that, Based on the predefined stub functions of each called function, the mapping relationship between the function name string and the stub function is added to the stub function mapping table.

6. The software unit test function stubping method according to claim 4, characterized in that, Based on the function stub status and test requirements of the current test case, if the stub function has a stub status switch, the mapping relationship between the function name string and the stub status sequence is added to the stub function stub status sequence mapping table.

7. A method for stubbing software unit test functions according to claim 6, characterized in that, If the test requires the called function to perform dynamic stubs, then a stub state sequence is defined; where, when a call needs to execute the real function, the value of this sequence is set to 0; and when a call needs to execute the stub function, the value of this sequence is set to 1.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method of claim 1.

Images