System and method for automated unit test generation of programming source code

Abstract

A system for generating a unit test based on source code is disclosed having a computer, a source code file, an abstract syntax tree, and at least one unit test. The source code file contains a source code having a plurality of constructs each belonging to a type including functions, return statements, attribute assignments, function calls, and branches. An abstract syntax tree is generated by a computer based on a source code and a plurality of constructions, the abstract syntax tree having a plurality of nodes, where each of the plurality of constructions in the source code has a corresponding node. At least one unit test is generated by a computer based on nodes of the abstract syntax tree and predefined rules, the unit test comprising at least one packet function corresponding to a function configuration or a branch configuration, and the unit test comprising at least one trial function corresponding to a return statement configuration, an attribute assignment configuration, or a function call configuration.

Description

Cross-references to related applications

[0001] This application is based on an international patent application (PCT) filed on July 13, 2023, for U.S. Patent Application No. 18 / 351,744, the disclosure of which is hereby expressly incorporated herein by reference. Technical Field

[0002] This disclosure relates to the automated generation of unit tests for programming source code. Specifically, this disclosure relates to static source code analysis for the automated generation of unit tests, including static source code analysis for the automated generation of unit tests in loosely typed languages ​​such as JavaScript. Background Technology

[0003] In computer programming, unit testing is used to test aspects or units of source code to determine if they function correctly and are ready for release and use. Unit testing is one of the most important methods for performing source code quality control. Unit tests can be used to check every result of every function. For example, the ability to run unit tests after changes have been made to the source code ensures that no additions or modifications will affect the integrity of the application.

[0004] Creating and maintaining unit tests is a very time-consuming and often repetitive task. Time is spent not only writing test scenarios but also writing code to set up and run the tests. Because it is a manual process, human error is possible, and no two sets of unit tests are likely to look alike, especially if they are created or maintained by different people or groups.

[0005] Another challenging issue arises with formatting test code and naming scenarios. While tools exist to check and enforce formatting rules for the code itself, variable and function names (including scenario titles) are unchecked and left to the programmer's discretion. This can lead to duplicate, inconsistent, or incorrect titles. Since programmers running unit tests may use titles as indicators to check test pass / fail, the results can be unintended or incorrect.

[0006] Some programmers use "code snippets" or "live templates" to make typing repetitive code patterns easier and to make writing test setup code easier. However, these features have three main drawbacks: 1) they cannot automatically generate test code, 2) they cannot automatically generate test headings, and 3) the editor is tied to a specific IDE (Software Development Environment), each with its own formatting. Summary of the Invention

[0007] Based on these and other needs in the art, it is desirable to provide a system, apparatus, and method that addresses at least some of the drawbacks associated with conventional unit test generation.

[0008] In one aspect of this disclosure, a system for generating unit tests based on source code can be provided. This system includes a computer coupled to a processor. The source code file may be computer-usable and contains source code with multiple constructs. Each of the multiple constructs belongs to a type, including functions, return statements, property assignments, function calls, and branches. An abstract syntax tree (AST) can be generated by the computer based on the source code and the multiple constructs. The AST has multiple nodes, where each of the multiple constructs in the source code has a corresponding node. At least one unit test can be generated by the computer based on the nodes of the AST and predefined rules. The unit test includes at least one grouped function corresponding to a function construct or a branch construct. The unit test includes at least one trial function corresponding to a return statement construct, a property assignment construct, or a function call construct.

[0009] In another aspect of this disclosure, a computer-implemented method may be provided, comprising: receiving at a computer a source code file having multiple constructs, each of the multiple constructs belonging to a type, such types including functions, return statements, property assignments, function calls, and branches; generating an abstract syntax tree based on the source code and the multiple constructs, the abstract syntax tree having multiple nodes, wherein each of the multiple constructs in the source code has a corresponding node; and generating unit tests based on the nodes and predefined rules, the unit tests including at least one grouped function corresponding to a function construct or a branch construct, and the unit tests including at least one trial function corresponding to a return statement construct, a property assignment construct, or a function call construct.

[0010] In another aspect of this disclosure, a non-transitory tangible computer-readable device is provided, which stores instructions that, when executed by a computing device, cause the computing device to perform operations, the operations including: receiving at a computer a source code file having multiple constructs, each of which belongs to a type including functions, return statements, property assignments, function calls, and branches; generating an abstract syntax tree based on the source code and the multiple constructs, the abstract syntax tree having multiple nodes, wherein each of the multiple constructs in the source code has a corresponding node; and generating unit tests based on the nodes and predefined rules, the unit tests including at least one grouped function corresponding to a function construct or a branch construct, and the unit tests including at least one trial function corresponding to a return statement construct, a property assignment construct, or a function call construct. Attached Figure Description

[0011] The purpose and advantages of this disclosure will become apparent upon consideration of the following detailed description in conjunction with the accompanying drawings, in which similar reference numerals consistently denote similar parts, and wherein: Figure 1 A schematic diagram of the system and method according to this disclosure is shown.

[0012] Figure 2 A schematic diagram illustrating the mapping between types and test functions according to this disclosure is shown.

[0013] Figure 3 The diagram shows a function called "foo()" that returns the string "bar" and its abstract syntax tree representation.

[0014] Figure 4 The method according to this disclosure is shown.

[0015] Figure 5 It shows that it can be used Figure 4 The example source code used in the method.

[0016] Figure 6 It shows Figure 5 The representation of the construct in the source code.

[0017] Figure 7 It shows that according to Figure 5 The abstract syntax tree generated from the source code.

[0018] Figure 8 It shows that according to Figure 5 source code and Figure 7 Unit tests generated from the abstract syntax tree.

[0019] Figure 9 It shows Figure 8 A formatted version of the unit test.

[0020] Figure 10 It shows Figure 8 A formatted version of the unit test.

[0021] Figure 11 An apparatus according to the present disclosure is shown, the apparatus being in accordance with Figure 1 and Figure 4 Systems and methods. Detailed Implementation

[0022] Although this disclosure has been described with reference to preferred embodiments and specific examples thereof, it will be apparent to those skilled in the art that other embodiments and examples can perform similar functions and / or achieve similar user experiences. All such equivalent embodiments and examples are within the spirit and scope of the invention, and are therefore contemplated and intended to be covered by the appended claims.

[0023] In accordance with regulations, this teaching has been described in more or less specific language regarding structural and methodological features. However, it should be understood that this teaching is not limited to the specific features shown and described, as the systems and methods disclosed herein include preferred forms that make this teaching effective. This disclosure is to be considered as illustrative of the invention and is not intended to limit the invention to the specific embodiments shown in the foregoing drawings or the following description.

[0024] For illustrative purposes rather than restrictive, specific details such as particular architectures, interfaces, and technologies are described to provide a thorough understanding. In other cases, detailed descriptions of well-known devices, circuits, and methods are omitted to avoid unnecessary obfuscation with details.

[0025] Generally, unless otherwise expressly defined herein, all terms used in the claims shall be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to elements, devices, components, apparatuses, steps, etc., shall be publicly interpreted as referring to at least one instance of an element, device, component, apparatus, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the exact order disclosed. The use of terms such as “first,” “second,” etc., for different features / components of this disclosure is intended only to distinguish features / components from other similar features / components, and not to assign any order or hierarchy to the features / components. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0026] In order to assist the Patent Office and any reader of any patent issued under this application in interpreting the appended claims, the applicant declares that no claim or claim element is expected to invoke 35 U.S.C. 112(f) unless the terms “means for…” or “steps for…” are expressly used in a particular claim.

[0027] While this teaching has been described above with reference to specific embodiments, it should be understood that this teaching is not limited to these disclosed embodiments. Many modifications and other embodiments will occur to those skilled in the art to which this application pertains, and these modifications and other embodiments are intended to be covered by both this disclosure and the appended claims. As will be understood by those skilled in the art relying on the disclosure in this specification and the accompanying drawings, the scope of this teaching is intended to be determined by a proper interpretation and construction of the appended claims and their legal equivalents. In describing the invention, it should be understood that many techniques and steps are disclosed. Each of these techniques has its own individual benefits, and each technique may also be used in combination with one or more of the other disclosed techniques, or in some cases with all other disclosed techniques. Therefore, for clarity, this description will avoid unnecessarily repeating every possible combination of the individual steps. However, upon reading the specification and claims, it should be understood that such combinations are fully within the scope of the invention and the claims.

[0028] Reference Figure 1 This disclosure describes a system and method 10 for generating unit tests using static source code analysis. Preferably, the system and method automatically generate unit tests by performing static analysis of the source code in an initial step.

[0029] According to some embodiments, systems and methods for generating unit tests can use one or more procedures for static source code analysis. In non-limiting examples, systems and methods can automate unit test generation by performing a comprehensive analysis of the source code in an initial step. The raw code, represented as a string, undergoes parsing and static analysis processes to extract constructs, identify relationships, and infer test scenarios.

[0030] The parsing algorithm used in the system dissects the original source code, breaking it down into individual tokens and understanding its structure, syntax, and semantics. In a non-restricted example, this process involves lexical analysis, where code is tokenized to identify keywords, identifiers, operators, and literals. The parsed code forms the basis for subsequent analysis. During the parsing phase, specific algorithms extract various constructs from the code. These constructs include, but are not limited to, variable declarations, function parameters, property assignments, and other language-specific elements. Each construct represents a different entity in the codebase.

[0031] For example, in a non-restricted example, the parsing algorithm identifies function declarations by analyzing function signatures and parameters. The parsing algorithm identifies property assignments by examining statements that assign values ​​to variables or object properties. By extracting these constructs, the system can gain a comprehensive understanding of the code's composition and structure.

[0032] Beyond extracting constructs, parsing and static analysis algorithms also establish relationships between these constructs. These relationships provide insights into the interactions and dependencies within the code. In a non-restricted example, the algorithm identifies parent-child relationships, sibling relationships, and nesting levels within the code. By understanding these relationships, the system gains a holistic view of the codebase.

[0033] The static analysis process goes beyond simple parsing; it also infers meaningful test scenarios based on the extracted constructs and their relationships. In the unrestricted example, the system employs various algorithms and techniques to generate test cases covering different code paths and behaviors. These algorithms consider the context and semantics of the code to make intelligent inferences about expected behavior.

[0034] For example, when a function call is encountered, the system analyzes the corresponding parameters to generate test cases for various execution scenarios. In an unrestricted example, the system can identify function calls with different parameter combinations and generate tests to verify the behavior of the called function under different input conditions. Furthermore, the static analysis process can consider control flow constructs, such as if statements, loops, and branching logic, to generate test scenarios covering all possible execution paths. In an unrestricted example, the system identifies conditions within if statements and generates tests to evaluate both true and false branches. This ensures comprehensive coverage of the conditional behavior of the code.

[0035] Parsing and static analysis algorithms can transform raw source code into an Abstract Syntax Tree (AST). An AST represents code as a tree structure, where each node corresponds to a construct in the code. In a non-restricted example, an AST captures the hierarchical relationships between different constructs, thus providing a high-level overview of the code's composition.

[0036] In an AST (Abstract Syntax Tree), each node represents a construct, such as a function declaration, variable assignment, or control flow statement. In unrestricted examples, the AST effectively organizes the components of the code and the relationships between them. This structured representation allows systems to browse the code, extract additional information, and apply further analysis techniques.

[0037] The generated AST provides a strong foundation for subsequent stages of the unit test generation process. The generated AST enables the system to traverse the code, identify relevant constructs, and extract additional details. In the unrestricted example, the AST helps identify constructs that require specific test scenarios or additional setup code, thereby ensuring comprehensive test coverage.

[0038] Therefore, parsing and static analysis algorithms can be configured to automatically generate unit tests. Parsing algorithms dissect the original source code to extract constructs, while the static analysis phase identifies relationships between these constructs and infers meaningful test scenarios. By employing these algorithms, the system can be configured to analyze the codebase to generate effective unit tests covering various code paths and behaviors.

[0039] In some embodiments, system 10 may include computer 1. Computer 1 may be or include processor 11, remote computer, computer server, network, memory, or any other computing resource, including mobile devices. Computer 1 may communicate with database 4, which may be a storage device attached to computer 1, a networked storage device, or an internet storage device. The computer may include or have access to... Figure 1 All elements depicted within the dashed rectangle. As a non-restrictive example, Figure 11 Server 1c can be computer 1.

[0040] Source code 2 is available on computer 1. Source code 2 may be in a source code file, available on computer 1's internal or removable memory, accessible via a network, or stored in a database accessible to computer 1 (e.g., database 4). Source code 2 may be written in programming language 21. Preferably, programming language 21 may be a loosely typed language (i.e., a language that does not require the definition of variables), such as JavaScript or one of its derivatives. The exposed systems and methods may be general and may be implemented in other languages ​​with their own structural characteristics for testing source code. Other loosely typed languages, such as Python and Ruby, have different characteristics in terms of the types of abstract syntax tree nodes to be handled, how internal intermediate objects are created to store code information, and how unit tests are written. Strongly typed languages, such as .NET and Java, may be more complex.

[0041] Source code 2 can have multiple constructs 22. Constructs 22 can be considered building blocks of the source code, providing structure and meaning. Each construct 22 can belong to a type 23 describing its role in the source code. Type 23 can include, but is not limited to, functions 231, branches 232, property assignments 233, function calls 234, and return statements 235. At a high level, a function 231 can be a subroutine typically written to perform a single task. A branch 232 can be a fork in the code, where a branch can only be used if certain logic allows it (i.e., if statements, while statements, for loops, etc.). A property assignment 233 assigns a value to a variable. A function call 234 can include code that seeks to run a function and passes variable arguments to the function. A return statement 235 can be the end of a function 231, through which a returned variable / result can be provided.

[0042] Type 23 can also be defined by their effect on the flow of the program or function within it. For example, a unit test should test return statement 235 to determine what value can be returned. Some types (such as property assignment 233 and function call 234) can include actions within function 231 that have effects outside the scope of that function. For example, property assignment 233 can include the assignment of a value to a variable outside function 231, and function call 234 can call other functions inside function 231 or as part of function 231. Finally, branch 232 can include if / else statements, switch statements, ternary operators, or any possible control flow of a function.

[0043] Systems and methods can be configured to leverage static source code analysis to create intermediate representations by traversing the Abstract Syntax Tree (AST). This intermediate representation serves as an object that captures necessary details about the code being analyzed, such as the properties being tested, the types of functions involved, and the necessary context for testing each function.

[0044] During AST traversal, the system targets specific node types within the syntax tree. This traversal involves a function that receives two arguments: the AST itself and an object specifying the node to be captured and the corresponding function to be executed. This function acts as a wizard for traversing the AST, allowing valuable information to be extracted from the nodes. For example, when a function declaration node is encountered in the AST, the system can extract the function's name and parameters. This information is crucial for generating relevant test scenarios covering various input configurations. Furthermore, when a return statement node is encountered, the system can extract the expected return value of the corresponding function. This enables the generation of test cases that verify the correctness of the function's output.

[0045] By traversing the Abstract Syntax Tree (AST) and extracting information from specific nodes, the system gains a comprehensive understanding of the code's structure and behavior. This information forms the basis for generating unit tests and ensuring their effectiveness in covering different aspects of the codebase. In a non-restrictive example, the system employs predefined rules that determine which nodes should be tested based on their relevance to specific construct types. These rules provide instructions or configuration information to the system for each construct type, allowing for the extraction of additional details from the corresponding nodes.

[0046] For example, if a node corresponds to a function declaration, predefined rules can instruct the system not only to extract the function's name and parameters, but also any additional context required to test that function. This context can include dependencies, mock objects, or setup requirements. Similarly, if a node corresponds to a return statement, rules can specify the expected return value to be compared with the actual output during testing. The unit test generation process involves creating test scenarios associated with constructs in the source code or nodes in the AST. Unit tests include two types of test scenarios: grouped functions and trial functions, also known as description functions and it functions, respectively.

[0047] Grouping functions can be used to create blocks that group related test cases together. These functions typically accept two arguments: a string describing the block and the function that groups the individual test cases. For example, a node associated with a function declaration in a unit test might have a grouping function that includes the function's name, such as `describe("foo")`. Similarly, a node associated with a branch construction might have a grouping function that includes the condition for that branch, such as `describe("'if param_a is true'…")`.

[0048] On the other hand, trial functions are generated for constructs such as property assignments, function calls, and return statements. These functions capture the actual test content and typically accept two arguments: a string describing what is being tested and a function containing the test logic. Each trial function can contain one or more expectations that define the expected behavior or result of the code being tested. In a non-restricted example, the system uses information extracted from the AST to generate relevant test scenarios within these grouped functions and trial functions. By incorporating details extracted from nodes, the system ensures that unit tests cover a wide range of code paths and behaviors, thus providing comprehensive test coverage.

[0049] The system and methodology can utilize AST traversal and static analysis to generate unit tests. By traversing the AST and extracting information from specific nodes, the system gains a deep understanding of the code's structure and behavior. The extracted details, combined with predefined rules, enable the generation of test scenarios covering different constructs and behaviors within the codebase. By leveraging grouping and trial functions, the system organizes test cases and captures necessary test content. This approach ensures effective unit test generation and comprehensive test coverage.

[0050] Predefined rule 41 can be used on computer 1. Rule 41 may be available in a file, internal to computer 1, or on removable storage, accessible via a network, or stored in a database accessible to computer 1 (e.g., database 4). Rule 41 may depend on the programming language 21 of source code 2. Rule 41 may be selected by the user or by computer 1 at runtime based on the programming language 21 of source code 2.

[0051] Computer 1 can use predefined rule 41 to determine whether to test the node corresponding to construct 22. For example, rule 41 can be configured to identify all nodes 14 corresponding to construct 22 of a specific type 23, and can also provide computer 1 with instructions or configuration information for each type 23, such as to extract additional information.

[0052] For example, if node 14 corresponds to function declaration type 231, then rule 41 can instruct computer 1 to extract the name of the function and the parameters of the function. As another example, if node 14 corresponds to function declaration type 231, then rule 41 can instruct computer 1 to extract the expected return value of the function.

[0053] Computer 1 can take source code 2 as input to generate unit test 3. Unit test 3 can include multiple test scenarios 31. Each test scenario can relate to a construct 22 in source code 3 or a node 14 in abstract syntax tree 3. Unit test 3 can have two types of test scenarios 31: grouping functions 311 and trial functions 312. Grouping functions 311 and trial functions 312 can also be referred to as description functions and it functions. Predefined rules can determine whether grouping functions 311 or trial functions 312 can be generated for node 14 based on the relevance of the node to the construct 22 of type 23. For example, as Figure 2 As shown, function 231 and branch 232 can be used to generate group function 311. Attribute assignment 233, function call 234, and return statement 235 can be used to generate trial function 312.

[0054] Grouping function 311 can be used to create blocks that group tests. Grouping function 311 can have two arguments: a string describing the block and a function that groups the test functions. Any node 14 associated with function 231 can have a grouping function 311 in unit test 3 that includes the name of function 231 (e.g., describe(“foo”)). Any node 14 associated with branch 232 can have a conditional grouping function 311 that includes it (e.g., describe(“'if param_a istrue'…”)).

[0055] Trial functions can be generated for any property assignment 233, function call 234, and return statement 235. A trial function 312 can have two arguments: a string describing what is being tested and a function containing the test content. Each trial function can contain an expectation, for example, that the function returns a literal value. An example title would be `it('returns "bar",...)`.

[0056] If unit test 3 is executed, result 32 will be generated. Result 32 can show whether the source code passed unit test 3 or failed unit test 3. If source code 2 failed unit test 3, result 32 can also provide suggestions on whether unit test 3 was passed.

[0057] Now explain Figure 1 The operation of system 10. In order to generate unit test 3, source code 2 can be parsed by computer 1, preferably as a string, to generate 12 a parse tree, such as an abstract syntax tree 13. The abstract syntax tree 13 can be a tree representation of source code 2, wherein each node 14 of tree 13 is a construct 22 that appears in source code 2. Figure 3 The abstract syntax tree representation 14a of the function 231a, which is called “foo”, is shown. The function 231a returns the string 235a “bar”.

[0058] The abstract syntax tree 13 can be traversed to identify nodes 14 corresponding to the construct 22 to be tested and extract relevant information. Computer 1 can use predefined rules 41 to determine whether to test the node 14 corresponding to construct 22. The abstract syntax tree 13 can be traversed by targeting specific nodes 14 of type 23 within the abstract syntax tree 13. As a non-restrictive example, the function receives two arguments: the abstract syntax tree 13 and rules 41 that identify which functions to execute at which nodes 14. The function can then traverse the abstract syntax tree 13, and when it finds a node 14 of one of the types 23 declared in its second argument, it can be executed to extract information from the node 14 in the abstract syntax tree 13 of the source code 2. By targeting specific nodes 14 of type 23 within the tree, the abstract syntax tree 13 representing the structure of the source code 2 can be traversed efficiently. This traversal process allows for the extraction of valuable information from the nodes, which is essential for generating unit tests and capturing the desired behavior of the code.

[0059] In one approach, a function can be used to traverse the AST by receiving the AST itself and rule 41 as parameters. These rules identify specific nodes 14 and the corresponding functions to be executed during the traversal. The function can then traverse the AST, examining each node encountered and executing the specified function whenever a node of a declared type is found. This enables the extraction of relevant information from nodes within the abstract syntax tree.

[0060] Alternative methods for traversing the AST can also be used to obtain suitable results. In alternative examples, the traversal algorithm can utilize pre-visitor functions and post-visitor functions. The pre-visitor function executes before traversing the child nodes of a specific node, while the post-visitor function executes after traversing the child nodes. These access functions can be defined to perform specific actions on nodes based on their type, allowing information to be extracted or desired operations to be performed during traversal. By implementing pre-visitor and post-visitor functions, the system can capture information from nodes in a controlled manner, providing flexibility and customization during traversal.

[0061] In another example, traversing an AST involves using a recursive algorithm. This recursive approach starts from the root node of the AST and recursively explores each child node, applying the necessary logic or operations at each step. By recursively traversing the tree structure, the system can systematically examine and process each node in a depth-first or breadth-first manner, depending on the requirements of the analysis or testing of the generation process. Recursive algorithms can be designed to handle different node types and corresponding operations for different node types, thus allowing for comprehensive AST traversal and information extraction.

[0062] Alternatively, a stack-based traversal approach can be considered. This approach involves maintaining a stack data structure to track nodes visited during traversal. The system can push one or more initial nodes onto the stack, then repeatedly pop nodes from the stack, check their properties and perform necessary actions, and push child nodes onto the stack for future exploration. This iterative traversal method provides an alternative to recursive methods and can be advantageous in scenarios where recursive implementations are infeasible or inefficient.

[0063] Depending on the specific requirements and constraints of the system, alternative methods for traversing the AST can be used individually or in combination. The choice of traversal method can depend on factors such as performance considerations, codebase complexity, and the level of control and customization required during the traversal process.

[0064] While the function-based methods described above are feasible for traversing the Abstract Syntax Tree (AST) and extracting information, alternative techniques can also be utilized, such as pre-access and post-access functions, recursive algorithms, and stack-based traversal. These alternative methods offer flexibility, customization, and efficiency in traversing the AST and capturing the necessary details for generating comprehensive unit tests. The choice of the most suitable traversal method can depend on various factors and considerations specific to the system requirements.

[0065] As another example, and refer to Figure 3 The computer 1 can traverse the abstract syntax tree 13a and identify nodes 14a of type FunctionDeclaration and ReturnStatement, which correspond to a constructor 22a with type function declaration 231a and type return statement 235a. The FunctionDeclaration node 14a informs the computer 1 that the function's name is "foo" and that the function has no parameters. The ReturnStatement node 14a indicates that there is only one return statement, and that the return statement returns a static string literal. To generate unit tests 3, the computer 1 can traverse the extracted nodes 14 and related information to create setup code and test scenarios 31 for each node 14, preferably in string format. This setup code can be configured to create the necessary context and environment to efficiently execute the test scenarios.

[0066] The setup code is customized according to the preferred test framework format, as each framework typically has its own conventions and functions for setting up the test environment. The setup code involves preparing the necessary context and defining the required variables or parameters for the function being tested to ensure the accurate execution of the test scenario. The format and content of the setup code can vary depending on the type of code being tested and the specific test framework used.

[0067] In a non-restricted example, a function could be provided that accepts a single argument `b` and returns the sum of `a` and `b` in the execution context (`this`). To properly test this function, the variable `a` needs to be defined within the context of the test scenario. The setup code will be responsible for creating that context and providing the necessary values.

[0068] For example, when using Jest as a testing framework in JavaScript, you can use the `beforeEach` block to create setup code. This block executes before each test scenario, ensuring that the function under test has a new and consistent context. In the summation function example, the setup code is provided as follows: beforeEach( ( ) =>{ context = { a: 2}; }); In this example, a context object is defined, and the variable 'a' is set to the value 2. This setting code ensures that 'a' is available in the test scenario and can be accessed in the function being tested.

[0069] The setup code created will be used in subsequent test scenarios. For example, in a test scenario designed to verify the result of calling the summation function with b = 3, the previously defined context can be used as follows: sum.call(context, 3); In this test scenario, the summation function is called with this context as the execution context (this), and 3 is passed as the parameter to b. The expected result of this execution is 5, since a is set to 2 and b is set to 3, resulting in 2 + 3 = 5.

[0070] Additionally, the setup phase can involve pre-defining function parameters. For example, if you want to test a summation function with a specific value of `b` in multiple test scenarios, you can define it in the setup code. This ensures consistency and avoids redundant code in each individual test scenario. Therefore, generating setup code can establish the necessary context and environment for accurately executing test scenarios. Setup code can be appropriately configured according to the format of the test framework and can be configured to include processes for defining variables, providing parameters, and creating the required context. By properly setting up the test environment, unit tests can effectively verify the behavior and correctness of the code under test.

[0071] For example, there can be a direct correlation between node 14 in the abstract syntax tree 13 and the resulting test scenario 31. Test scenario 31 may include checking whether a return statement (if present) returns the expected value, or checking whether attribute assignment 233 and / or function call 234 are executed correctly. By analyzing the value of node 14, computer 1 can determine how to write test scenario 31. If node 14 has a literal value, that value is sufficient. However, any other type of value can be investigated by examining the types of its child nodes.

[0072] As an example, refer to Figure 3 It can be expected that the return statement will return the literal value "bar", and computer 1 can generate test scenario 31 for this situation.

[0073] In one example, computer 1 can create an empty test string and group test scenarios 31 according to the function 231 or branch 232 to which they belong. Then, for each test scenario 31, computer 1 can create the necessary code, including a grouping function, a trial function, and a `beforeEach` statement. Computer 1 can append the code to the empty test string. If any setup is required, such as creating a mocking context for side effects, this setup can be established within the relevant grouping function 311 or trial function 312.

[0074] To name or title test scenario 31, computer 1 can use a function name (which can be obtained from function declaration 231 node 14) and sufficient information about what it returns to generate a text string explaining the test case. For Figure 3 In a non-restrictive example, the title could be "Function foo returns the string 'bar'". The same process applies to more complex scenarios. As another example, if a function executes another function call with specific parameters, then these nodes can also be inspected, and enough information can be extracted to generate the title and the scenario to be tested.

[0075] Unit tests can be created in string format, and syntax designed for frameworks that work with programming languages ​​can be used. For JavaScript, such frameworks could include Jest or Jasmine, as non-restrictive examples.

[0076] After writing unit test 3, computer 1 can format unit test 16, for example, by running a code inspection and formatting script. The code inspection script can analyze the generated unit test 16 and mark or correct errors, program vulnerabilities, stylistic errors, and / or suspicious constructs. The formatting script can improve the readability of unit test 16 for readers, for example, by including line breaks and / or spaces. This can turn unit test 3 into human-readable text, for example, by making variable names easier to read or by splitting unit test 3 with formatting or spacing applied. In a non-limiting example, formatting 16 can be done using software such as Prettier or ESLint.

[0077] Unit test 3 can be output, for example, to the standard console output of computer 1 for display on a monitor, or to a file that can be saved in a computer-accessible location, such as database 4. The user can choose where to save the output unit test 3. Alternatively, the output unit test 3 can be used as input to another process or program, such as a process or program used to execute unit test 3.

[0078] Unit test 3 can be executed by computer 1 17, and result 32 can be generated, displayed, and / or saved to a file by computer 1. Result 32 can indicate whether source code 2 has passed unit test 3, whether source code 2 has passed test scenario 31, and if any part fails, provide suggestions for improving source code 2 to pass unit test 3.

[0079] Figures 4 to 10 Exemplary and non-limiting examples of the systems and methods disclosed herein are shown.

[0080] Figure 4 The method according to this disclosure is shown. Figure 4 The method can be with Figure 1 Used together with the system 10 shown, or with Figure 11 The system shown is used together. This method receives source code 121m. As described above, the computer can input source code 2, which can have a construction 22 of programming language 21 and type 23. Figure 5 A non-restrictive example of source code 2b is shown in the figure.

[0081] An abstract syntax tree 12m can be generated from the input source code 121m. As mentioned above, the abstract syntax tree 13 can be traversed by targeting a specific node 14 of type 23 in the abstract syntax tree 13.

[0082] As a non-restrictive example, and as Figure 6 As shown, when generating the abstract syntax tree 12m, an intermediate step can be taken, in which the construct 22b can be extracted from the source code 2b. Then, features and information about the construct 22b can be extracted from the source code 2b to generate... Figure 7 The abstract syntax tree 13b shown is shown.

[0083] like Figure 8 As shown, unit tests 3b can be generated based on the abstract syntax tree 13b. In some embodiments, the process of generating unit tests 3b involves traversing the extracted nodes 14b and related information of the extracted nodes 14bd to create the necessary setup code and test scenarios 31 for each node 14b. This allows for comprehensive test coverage of the analyzed code. In the generation of unit tests 3b, grouping functions 311 and trial functions 312 are generated based on the nodes 14b existing in the abstract syntax tree 13b.

[0084] Predefined rules, such as the previously discussed predefined rule 41, play a crucial role in guiding the generation of unit tests based on the relevance of node 14b to specific constructs 22 and type 23. These rules provide instructions and guidance for generating appropriate test scenarios for each node, thereby ensuring effective and meaningful testing.

[0085] like Figure 7 and Figure 10 As shown in the non-restrictive example, node 14b corresponds to grouping function 311b and trial function 312b. For example, "default" in Figure 5 The function is defined as having "data" and "methods". "Default", "data", "methods", and "setLoading" are transformed into group functions 311b in unit test 3. Trial function 312 is generated to test whether "loading" and "isOpen" are false, and whether setLoading sets the value of loading to true.

[0086] In non-restrictive examples, such as Figure 5As shown, property assignment can be considered within the `setLoading` function. In this case, specific test scenarios are needed to verify that the `loading` property is correctly assigned a value of true. The corresponding unit test 3b will include test scenarios designed to determine whether the assignment occurs as expected. To achieve this, the initial value of `loading` can be set to a value other than true during the setup phase. This ensures that subsequent test scenarios only focus on verifying the expected assignment behavior.

[0087] In the embodiments described herein, the system and methods are configured to provide flexibility and adaptability in generating unit tests for different scenarios and constructs. By incorporating predefined rules and utilizing information extracted from the abstract syntax tree 13b, the unit test generation process can be customized for various code structures and types. This allows for comprehensive coverage of different types of constructs, including function declarations, property assignments, return statements, and so on.

[0088] The format and structure of unit tests can vary depending on the chosen testing framework or convention. The system and methodology are designed to adapt to different testing frameworks and their specific requirements. For example, in JavaScript, testing frameworks (such as Jest, Jasmine, or Mocha) may have their own preferred formats for organizing test scenarios and assertions.

[0089] Within the context of the generated unit test 3b, the grouping function 311 and the trial function 312 can be organized in a manner consistent with the format of the selected test framework. These functions are used to group related test scenarios and provide a clear structure for organizing and executing tests. The specific format and naming conventions used in unit test 3b are determined by the selected test framework and the developers' preferences.

[0090] As described in this article, the process for generating unit tests can leverage static source code analysis and predefined rules. Unit tests are tailored to the structure and constructs within the analyzed code, allowing for comprehensive test coverage. Due to its flexibility in adapting to different testing frameworks and their conventions, the generated unit tests follow a preferred format, and provide a clear structure for organizing and executing tests. The provided examples demonstrate the system's ability to generate test scenarios for different constructs, thereby ensuring comprehensive verification of the code's behavior.

[0091] Optional steps for formatting unit test 3b (16m) and executing unit test 3b (17m) are also shown. An example of formatting unit test 3b is provided in... Figure 9 and Figure 10 As shown, these examples are implemented using Prettier and ESLint.

[0092] like Figure 11 As shown, a system according to this disclosure may include source code 2c, server 1c, and unit tests 3c. Source code 2c can be provided by server 1c via... Figure 1 or Figure 4 The method shown is used to generate unit test 3c.

Claims

1. A system for generating unit tests based on source code, comprising: Computer, the computer being coupled to a processor; The computer-usable source code file contains source code with multiple constructs, each of which belongs to a type, including functions, return statements, property assignments, function calls, and branches; An abstract syntax tree, generated by the computer based on the source code and the plurality of constructs, the abstract syntax tree having a plurality of nodes, wherein each of the plurality of constructs in the source code has a corresponding node; At least one unit test, generated by the computer based on the nodes and predefined rules of the abstract syntax tree, the unit test including at least one grouping function corresponding to a function construct or branch construct, and the unit test including at least one trial function corresponding to a return statement construct, property assignment construct, or function call construct.

2. The system according to claim 1 further includes computer-executable code for formatting the unit test.

3. The system according to claim 2, wherein, Formatting the unit tests includes making them human-readable.

4. The system according to claim 1 further includes computer-executable code for performing the unit tests and generating results.

5. The system according to claim 1, wherein, The source code is written in JavaScript or a JavaScript-derived language.

6. The system according to claim 1, wherein, The source code is written in a loosely typed language.

7. The system according to claim 1, wherein, The predefined rules are selected based on the programming language of the source code, and the predefined rules provide instructions on how to generate unit tests for a specific node or construct.

8. A computer-implemented method, comprising: Receive a source code file with multiple constructs at a computer, each of which belongs to a type, including functions, return statements, property assignments, function calls, and branches; An abstract syntax tree is generated based on the source code and the plurality of constructs. The abstract syntax tree has a plurality of nodes, wherein each of the plurality of constructs in the source code has a corresponding node. Unit tests are generated based on the nodes and predefined rules. The unit tests include at least one group function corresponding to a function constructor or branch constructor, and the unit tests include at least one trial function corresponding to a return statement constructor, property assignment constructor, or function call constructor.

9. The method of claim 8, further comprising formatting the unit test.

10. The method according to claim 9, wherein, Formatting the unit tests includes making them human-readable.

11. The method of claim 8, further comprising performing the unit test and generating results.

12. The method according to claim 8, wherein, The source code is written in JavaScript or a JavaScript-derived language.

13. The method according to claim 8, wherein, The source code is written in a loosely typed language.

14. The method according to claim 8, wherein, The predefined rules are selected based on the programming language of the source code, and the predefined rules provide instructions on how to generate unit tests for a specific node or construct.

15. A non-transitory tangible computer-readable device, the non-transitory tangible computer-readable device storing instructions that, when executed by a computing device, cause the computing device to perform an operation, the operation comprising: Receive a source code file with multiple constructs at a computer, each of which belongs to a type, including functions, return statements, property assignments, function calls, and branches; An abstract syntax tree is generated based on the source code and the plurality of constructs. The abstract syntax tree has a plurality of nodes, wherein each of the plurality of constructs in the source code has a corresponding node. as well as Unit tests are generated based on the nodes and predefined rules. The unit tests include at least one group function corresponding to a function constructor or branch constructor, and the unit tests include at least one trial function corresponding to a return statement constructor, property assignment constructor, or function call constructor.

16. The computer-readable device according to claim 15, wherein, The operation also includes formatting the unit test, which includes making the unit test human-readable.

17. The computer-readable device according to claim 15, wherein, The operation also includes performing the unit test and generating results.

18. The computer-readable device according to claim 15, wherein, The source code is written in JavaScript or a JavaScript-derived language.

19. The computer-readable device according to claim 15, wherein, The source code is written in a loosely typed language.

20. The computer-readable device of claim 15, wherein, The predefined rules are selected based on the programming language of the source code, and the predefined rules provide instructions on how to generate unit tests for a specific node or construct.

Images