Unit test code generation method, system, device and medium

Abstract

The application discloses a unit test code generation method, system, device and medium, which is applied to the technical field of code generation and includes the following steps: obtaining a structured meta-information set and a source code syntax structure model by performing program structure interface analysis and abstract syntax tree analysis on target engineering code; generating a structured context feature vector based on the structured meta-information set and the source code syntax structure model; searching a historical test case sample set from a historical test case database, wherein the historical test case sample set meets a matching condition in terms of global line coverage weighted similarity with the structured context feature vector; filling a Prompt template of different test sub-tasks based on the historical test case sample set and the structured context data through an Agent intelligent agent; generating different modular test codes by using different test code generation models; and performing closed-loop verification after integrating the different modular test codes into unit test codes, so that the code quality, practicality and adaptability are improved.

Description

Technical Field

[0001] This application relates to the field of code generation technology, and in particular to a method, system, device and medium for generating unit test code. Background Technology

[0002] Software testing is often used to verify the correctness, stability, and security of software functions. Its testing objects can cover different levels, such as the smallest unit, module, system, and interface. Test types include unit testing, integration testing, interface testing, and system testing. Among these, unit testing is the prerequisite and foundation for the effective implementation of other test types. Existing unit test code generation methods are mainly divided into two categories:

[0003] Template-driven approach: Developers manually complete the business logic-related code using predefined, fixed test frameworks and sample templates. Its core drawback is its reliance on manual intervention and lack of flexibility, making it difficult to handle complex business logic and multi-language environments.

[0004] Single-model driven approach: Automated code generation is achieved through a single model. Its core drawbacks are: test cases often fail to cover boundary conditions and exceptional scenarios, resulting in insufficient coverage; it is difficult to integrate code comments, dependencies, and historical test cases, leading to limited contextual understanding and a disconnect between test code and actual project requirements; and the single model is prone to unstable output and poor robustness.

[0005] In summary, existing unit test code generation methods are insufficient to meet the requirements for high-quality, highly automated, and engineering-adaptable unit test code generation. There is an urgent need for a new unit test code generation method to improve the coverage, robustness, adaptability, and automation level of unit test code generation. Summary of the Invention

[0006] This application provides a unit test code generation method, system, device, and medium to address the problems of insufficient coverage, poor adaptability and robustness, and low automation level in existing unit test code generation methods. The technical solution provided by this application is as follows:

[0007] On the one hand, this application provides a unit test code generation method applied to the Chisi performance platform, including:

[0008] The target project code file is parsed by program structure interface parsing and abstract syntax tree parsing to obtain a set of structured meta-information and a source code syntax structure model. Based on the set of structured meta-information and the source code syntax structure model, the structured context data of the target project code file is determined. The structured context data is vectorized to obtain the structured context feature vector of the target project code file.

[0009] A coverage-weighted similarity retrieval algorithm is used to retrieve historical test case samples from the historical test case database that meet the matching condition of global line coverage-weighted similarity to the structured context feature vector of the target project code file. The historical test case database includes each historical test case sample and its corresponding structured context feature vector and global line coverage.

[0010] Using an agent, the system determines the various test subtasks corresponding to the target project code file based on the structured context data and historical test case sample set. It then fills the Prompt templates for different test subtasks with the historical test case sample set and structured context data to obtain PromptBundle data for each subtask. Based on this PromptBundle data, it calls dedicated test code generation models for each subtask to generate unit test code snippets. These snippets are then integrated into candidate unit test code for the target project code file. The candidate unit test code is iteratively validated locally and updated with closed-loop feedback until a preset quality standard is met. Finally, the last updated candidate unit test code is determined as the final unit test code.

[0011] Optionally, structured context data is determined based on the set of structured meta-information and the source code syntax structure model, including:

[0012] Call CoverageSuitesManager to obtain the current coverage engine data;

[0013] For each method in the structured metadata set, the row-level coverage array is collected by calling fileName+startLine / endLine based on the current coverage engine data. After calculating the method-level coverage metric based on the row-level coverage array, the row-level coverage array and the method-level coverage metric are written back to the corresponding node in the structured metadata set to obtain the structured context data.

[0014] Optionally, a coverage-weighted similarity retrieval algorithm is used to retrieve historical test case samples from the historical test case database that meet the matching condition of global row coverage-weighted similarity with the structured context feature vector of the target project code file. This retrieves these samples to form a historical test case sample set, including:

[0015] Based on the structured context feature vector of the target project code file and the structured context feature vector of each historical test case sample in the historical test case database, the similarity between the target project code file and the project code of each historical test case sample is calculated.

[0016] Based on the similarity between the target project code file and the project code of each historical test case sample, as well as the global line coverage of each historical test case sample, calculate the weighted similarity of the global line coverage between the target project code file and each historical test case sample.

[0017] A set of historical test case samples is formed by selecting historical test case samples from each historical test case sample that meet the matching conditions based on the global row coverage weighted similarity.

[0018] Optionally, the unit test code generation method provided in this application also includes:

[0019] When the global line coverage of each historical test case sample in the historical test case sample set is lower than the coverage threshold, or when the comprehensive quality score of the unit test code segment corresponding to different test subtasks is lower than the score threshold, the historical test case sample set of the target project code file is supplemented by retrieving from the historical test case database based on the supplementary retrieval strategy.

[0020] Based on the supplemented historical test case sample set and the structured context data of the target project code file, unit test code snippets corresponding to different test subtasks are regenerated.

[0021] Optionally, PromptBundle data for different test subtasks is obtained by populating the Prompt templates corresponding to different test subtasks based on the historical test case sample set and structured context data, including:

[0022] Extract the key code portions that match the business logic and test requirements of the target project code file from each historical test case sample in the historical test case sample set;

[0023] The key code parts in each historical test case sample that match the business logic and test requirements of the target project code file are adapted and integrated according to the structure and semantics of the target project code file to obtain historical test case fragments that match the target project code file.

[0024] Historical test case fragments and structured context data are populated into the corresponding placeholders in the Prompt templates for different test subtasks to obtain PromptBundle data for different test subtasks.

[0025] Optionally, the unit test code snippets corresponding to different test subtasks are integrated into candidate unit test code corresponding to the target project code file, including:

[0026] The candidate unit test code corresponding to the target project code file is obtained by voting and merging the unit test code snippets corresponding to different test subtasks and performing static syntax completion.

[0027] Optionally, the candidate unit test code is verified locally and updated with closed-loop feedback, including:

[0028] The candidate unit test code is locally compiled, locally run, and global line coverage is collected and processed to obtain code execution logs and global line coverage.

[0029] Local runtime feedback data for generating candidate unit test code based on code execution logs and global line coverage;

[0030] When it is determined that the local running feedback data does not meet the preset quality standards, the local running feedback data is fed back into the Prompt template corresponding to different test subtasks to be refilled and the updated PromptBundle data corresponding to different test subtasks is obtained.

[0031] Updated candidate unit test code is generated based on the updated PromptBundle data corresponding to different test subtasks.

[0032] On the other hand, this application provides a unit test code generation system applied to the Chisi performance platform, including:

[0033] The source code parsing module is used to parse the program structure interface and abstract syntax tree of the target project code file to obtain a set of structured meta-information and a source code syntax structure model;

[0034] The feature extraction module is used to determine the structured context data of the target project code file based on the structured meta-information set and the source code syntax structure model, and to vectorize the structured context data to obtain the structured context feature vector of the target project code file.

[0035] The historical retrieval module is used to retrieve historical test case samples from the historical test case database that meet the matching condition of global row coverage weighted similarity of the structured context feature vector of the target project code file, using a coverage weighted similarity retrieval algorithm. The historical test case database includes each historical test case sample and its corresponding structured context feature vector and global row coverage.

[0036] The code generation module, through an agent, determines the various test subtasks corresponding to the target project code file based on the structured context data and historical test case sample set of the target project code file. It then fills the Prompt templates for different test subtasks with the historical test case sample set and structured context data to obtain PromptBundle data for each subtask. Based on the PromptBundle data, it calls dedicated test code generation models for each subtask to generate unit test code snippets. These snippets are then integrated into candidate unit test code for the target project code file. The candidate unit test code is iteratively validated locally and updated with closed-loop feedback until a preset quality standard is met. Finally, the last updated candidate unit test code is determined as the final unit test code.

[0037] On the other hand, this application provides an electronic device, including 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 above-described unit test code generation method.

[0038] On the other hand, this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the above-described unit test code generation method.

[0039] The beneficial effects of this application are as follows:

[0040] (1) Significantly improve the coverage and accuracy of unit test code: The coverage-weighted similarity retrieval algorithm prioritizes the recall of historical test samples with high coverage and semantic similarity, and the Prompt example itself has high coverage characteristics, thereby improving the average line coverage and boundary / abnormal test case hit rate of the generated candidate unit test code.

[0041] (2) Achieve a closed loop of generation-verification-optimization and reduce the cost of manual intervention: After the Agent generates candidate unit test code based on the historical test case sample set and structured context data, it iterates the candidate unit test code for local running verification and closed loop feedback update until the preset quality standard is met and the final unit test code is output. The whole process does not require manual modification of assertions or import statements, which effectively improves the efficiency of test development.

[0042] (3) Possesses multi-model collaboration and task adaptation capabilities, improving generation stability: The test class skeleton, normal path, abnormal boundary, and coverage completion are separated into independent test sub-tasks, and the dedicated test code generation model of each test sub-task is called for processing, which can improve the pass rate of candidate unit test code and reduce the failure rate of candidate unit test code.

[0043] (4) Compatible with multiple languages ​​and private deployment, ensuring data security: The historical test case database and Agent orchestration layer both support local installation. Historical test case samples, global row coverage, etc. can be stored on the local intranet, meeting the compliance requirements of industries such as finance and telecommunications for source code not leaving the domain, and ensuring data security.

[0044] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, are illustrative and descriptive in nature and are used to interpret this application, but do not constitute an undue limitation of this application. In the drawings:

[0046] Figure 1 This is a simplified flowchart illustrating the unit test code generation method in the embodiments of this application;

[0047] Figure 2 This is a schematic diagram outlining the process of generating unit test code in an embodiment of this application.

[0048] Figure 3 This is a schematic diagram illustrating the specific process of the unit test code generation method in the embodiments of this application;

[0049] Figure 4 This is a schematic diagram of the composition structure of the unit test code generation system in the embodiments of this application;

[0050] Figure 5 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the embodiments and accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0052] The Chisi Performance Platform adheres to the BizDevSecOps philosophy, integrating three dimensions: business development (Biz), R&D delivery (Dev), and security operations (SecOps). It constructs an automated R&D system covering the entire lifecycle, including requirements, design, development, testing, release, and security compliance. Within this system, the unit test code generation system provided in this application, as an AI-powered intelligent R&D assistance and testing closed-loop sub-module of the Chisi Performance Platform, is a key component in achieving end-to-end intelligentization and quality-driven delivery within the BizDevSecOps framework. The unit test code generation system includes:

[0053] (1) Intelligent Connection Layer between R&D and Testing (AI Testing Copilot)

[0054] By integrating the IDE's plugin mechanism, it achieves automatic parsing of source code, context understanding, and intelligent generation of unit test code. It seamlessly integrates manual test design with model-generated testing, building an intelligent bridge between development, testing, and verification in the R&D process, significantly improving the efficiency and accuracy of test generation.

[0055] (2) Intelligent test feedback closed loop layer (Feedback & Optimization Loop)

[0056] By deeply integrating with the Chisi Performance Platform's Continuous Integration (CI) pipeline and Continuous Testing (CT) module, it can automatically collect runtime feedback such as compilation errors, assertion failures, and insufficient coverage after test execution. Based on the feedback information, it can dynamically adjust the Prompt template or trigger the Agent's repair process, thereby achieving self-optimization and evolution of test code and forming a closed loop of AI generation—CI verification—AI repair—re-verification.

[0057] (3) Efficiency Intelligence Layer

[0058] The ChiSi Performance Platform provides an automated interface for reporting code quality and coverage metrics between its project management, artifact management, and release management modules. Generated test results and metrics are fed back to the ChiSi Performance dashboard in real time to measure the R&D team's unit test maturity, automation level, and code stability. It also supports the continuous accumulation of knowledge from the historical test case database, enabling cross-project and cross-version experience transfer through semantic vectorization of historical generated data and fix samples.

[0059] (4) Security and compliance protection layer (Secure-by-Design Support)

[0060] By employing localized deployment and model invocation isolation mechanisms, the entire process of test code generation and source code analysis is ensured to comply with the financial industry's compliance requirements. Within the Chisi Performance Platform's security management module, local vectorization and privacy-de-identifying technologies are used to avoid potential data leakage risks during model invocations, achieving proactive security and intrinsic compliance.

[0061] (5) CI / CD Intelligent Collaboration Layer (IDE–Pipeline Loopback Integration)

[0062] Test code generated in the IDE can be automatically submitted to the Jenkins / pipeline management module of the Chisi Performance Platform, triggering test task execution. After the pipeline execution is complete, test logs, coverage reports, and performance metrics are automatically sent back to the IDE, providing real-time feedback. This closed-loop mechanism allows developers to complete the entire chain of operations from test generation to execution, result analysis, and secondary optimization without switching environments.

[0063] Based on this, embodiments of this application provide a method for generating unit test code, see below. Figure 1 As shown, the general flow of the unit test code generation method provided in this application embodiment is as follows:

[0064] S101: Perform program structure interface parsing and abstract syntax tree parsing on the target project code file to obtain a set of structured meta-information and a source code syntax structure model. Based on the set of structured meta-information and the source code syntax structure model, determine the structured context data of the target project code file. Vectorize the structured context data to obtain the structured context feature vector of the target project code file.

[0065] In this embodiment of the application, when performing program structure interface parsing and abstract syntax tree parsing on the target project code file to obtain a set of structured meta-information and a source code syntax structure model, the following methods may be used, but are not limited to:

[0066] The target project code file is parsed using the PSI function provided by the IDE, extracting structural information such as classes, methods, parameters, and return value types, and a native PSI abstract syntax tree (Program Structure Interface Tree) is constructed based on this structural information. A test coverage matrix is ​​obtained using the IntelliJ Coverage API provided by the IDE. Furthermore, the project analysis function provided by the IDE analyzes the build configuration file (such as Maven's pom.xml or Gradle's build.gradle) of the project containing the target project code file to extract project dependencies, and a dependency graph is constructed based on these dependencies. The PSI abstract syntax tree, test coverage matrix, and dependency graph are then integrated to form a structured meta-information set and a source code syntax structure model. Finally, structured context data is determined based on the structured meta-information set and the source code syntax structure model.

[0067] In this embodiment of the application, when determining the structured context data based on the structured meta-information set and the source code syntax structure model, the following methods may be used, but are not limited to:

[0068] Call CoverageSuitesManager to obtain the current coverage engine data;

[0069] For each method in the structured metadata set, a line-level coverage array is collected based on the current coverage engine data by calling fileName (name of the target project code file) + startLine (start line number of the code snippet) / endLine (end line number of the code snippet). After calculating the method-level coverage metric based on the line-level coverage array, the line-level coverage array and the method-level coverage metric are written back to the corresponding node in the structured metadata set to obtain the structured context data.

[0070] In this embodiment of the application, when vectorizing the structured context data to obtain the structured context feature vector of the target project code file, the following methods may be used, but are not limited to:

[0071] By embedding the model, structured context data is serialized into structured JSON data as a structured context feature vector. This structured context feature vector, used as input to the test code generation models for subsequent test subtasks, significantly reduces the code generation quality degradation caused by structure inference in the test code generation models. Furthermore, a runtime call graph (Java Flight Recorder, JFR) can be combined to generate four-dimensional context feature data containing syntax, coverage, dependencies, and runtime calls. This four-dimensional context feature data is vectorized to obtain a structured context feature vector, which is used to enhance the quality and context relevance of unit test code generation.

[0072] S102: Using a coverage-weighted similarity retrieval algorithm, historical test case samples that meet the matching condition of global row coverage-weighted similarity with the structured context feature vector of the target project code file are retrieved from the historical test case database to form a historical test case sample set; wherein, the historical test case database includes each historical test case sample and the structured context feature vector and global row coverage corresponding to each historical test case sample.

[0073] In this embodiment of the application, when using a coverage-weighted similarity retrieval algorithm to retrieve historical test case samples from the historical test case database that meet the matching condition of global row coverage-weighted similarity with the structured context feature vector of the target project code file, and forming a historical test case sample set, the following methods may be used, but are not limited to:

[0074] Based on the structured context feature vector of the target project code file and the structured context feature vector of each historical test case sample in the historical test case database, the similarity between the target project code file and the project code of each historical test case sample is calculated.

[0075] Based on the similarity between the target project code file and the project code of each historical test case sample, as well as the global line coverage of each historical test case sample, calculate the weighted similarity of the global line coverage between the target project code file and each historical test case sample.

[0076] A set of historical test case samples is formed by selecting historical test case samples from each historical test case sample that meet the matching conditions based on the global row coverage weighted similarity.

[0077] Furthermore, in this embodiment, when using a coverage-weighted similarity retrieval algorithm to retrieve historical test case samples from the historical test case database that meet the matching condition of global row coverage-weighted similarity with the structured context feature vector of the target project code file, and forming a historical test case sample set, if the global row coverage of each historical test case sample in the historical test case sample set is lower than the coverage threshold, a supplementary retrieval strategy can be used to supplement the historical test case sample set of the target project code file from the historical test case database. The supplementary retrieval strategy includes, but is not limited to, at least one of: expanding the retrieval scope, changing the embedding model, and patterned retrieval; expanding the retrieval scope can be achieved by increasing the number of candidate samples K, for example, by introducing a new retrieval scope. K represents the initial number of historical test case samples returned when retrieving from the historical test case database. That is, the K historical test case samples that are most similar to the structured context feature vector of the target project code file are initially retrieved from the historical test case database. This is the upper limit set for the number of search results, used to prevent the number of returned samples from increasing indefinitely when the search scope is expanded; changing the embedding model can be done by switching to an embedding model with a larger parameter scale, re-extracting the structured context feature vector, and then performing coverage-weighted similarity retrieval to improve the semantic expressiveness of the retrieval; patterned retrieval can be done by using patterned methods such as text filtering to filter historical test case samples that are more relevant to the target project code file, for example, filtering code snippets containing specific annotations (such as @Test) or method signatures through regular expressions.

[0078] S103: Using an agent, determine the various test subtasks corresponding to the target project code file based on the structured context data and historical test case sample set of the target project code file. Fill the Prompt templates corresponding to different test subtasks with the historical test case sample set and structured context data to obtain PromptBundle data for different test subtasks. Based on the PromptBundle data for different test subtasks, call the dedicated test code generation model for different test subtasks to generate unit test code snippets for different test subtasks. Integrate the unit test code snippets for different test subtasks into candidate unit test code corresponding to the target project code file. Iterate the candidate unit test code for local execution verification and closed-loop feedback updates until the preset quality standard is met. Then, determine the last updated candidate unit test code as the final unit test code.

[0079] In this embodiment of the application, when determining the various test subtasks corresponding to the target project code file based on the structured context data of the target project code file and the historical test case sample set through the Agent intelligent agent, the following methods may be used, but are not limited to:

[0080] Based on the structured context data and historical test case sample set of the target project code file, the agent determines the code structure information (such as class structure and method structure), test task type (such as test class generation, functional testing, exception and boundary testing, and coverage optimization), code complexity metrics (such as cyclomatic complexity and line count), historical test case patterns, and global line coverage of the target project code file. Based on this information, the agent also determines the various test sub-tasks corresponding to the target project code file. For example, the test code generation task for the target project code file can be broken down into the following sub-tasks:

[0081] Test Subtask 1: Generate test class structure and import packages;

[0082] Test Subtask 2: Generate test cases for the target method;

[0083] Test Subtask 3: Generate abnormal scenarios and boundary conditions;

[0084] Test Subtask 4: Verify coverage requirements and optimize test logic.

[0085] In this embodiment of the application, when using an Agent to fill the Prompt templates corresponding to different test subtasks with historical test case sample sets and structured context data to obtain PromptBundle data for different test subtasks, the following methods may be used, but are not limited to:

[0086] Extract the key code portions that match the business logic and test requirements of the target project code file from each historical test case sample in the historical test case sample set;

[0087] The key code parts in each historical test case sample that match the business logic and test requirements of the target project code file are adapted and integrated according to the structure and semantics of the target project code file to obtain historical test case fragments that match the target project code file.

[0088] Historical test case fragments and structured context data are populated into the corresponding placeholders in the Prompt templates for different test subtasks to obtain PromptBundle data for different test subtasks.

[0089] In this embodiment of the application, when the Agent intelligent agent calls the dedicated test code generation model for different test subtasks to generate unit test code snippets for different test subtasks based on the PromptBundle data corresponding to different test subtasks, the following methods can be used, but are not limited to:

[0090] (1) Test class generation task

[0091] PromptBundle data preparation: Extract context information related to test class generation from the PromptBundle data, including the target class name, package declaration, member variables, constructor, and the class's dependencies in the project.

[0092] Model Invocation: Invokes a code generation model specifically designed for test class generation. This model is trained on a large number of test class code samples and can generate test class framework code that conforms to the target class structure and project specifications based on the input context information.

[0093] Code snippet generation: The generated test class code snippet includes the class declaration of the test class, usually identified by the suffix "Test", such as the test class generated for the target class "Calculator" is "CalculatorTest"; it includes necessary import statements, such as importing the class under test, annotations and assertion classes related to the test framework, etc.; it also includes the corresponding test class member variable and constructor initialization code generated based on the member variables and constructor of the target class.

[0094] Related to other tasks: The generated test class code snippets serve as the basic framework for subsequent functional testing, exception and boundary testing, and test methods generated by subsequent tasks will be added to this test class.

[0095] (2) Functional testing tasks

[0096] PromptBundle data preparation: Extract the functional description, method signature, parameter types, and normal input / output examples of the target method from the PromptBundle data, and combine this with the existing test class framework information in the test class generation task.

[0097] Model Invocation: Invokes the code generation model for functional testing. This model understands the functional logic of the target method and generates test code based on the input context information to verify the method's behavior under normal input conditions.

[0098] Code snippet generation: The generated test method code snippet includes the declaration of the functional test method, usually identified by the prefix "test", such as "testAdd" indicating a functional test of the "add" method; it contains the execution logic of the test method, generates corresponding test data according to the parameter types of the target method, calls the target method and uses assertion statements to verify whether the return result matches the expectation.

[0099] Related to other tasks: The test methods generated by the functional test task are the specific implementations of the test class's functions. Subsequent exception and boundary test tasks will further supplement and improve the test methods in the test class to cover the behavior of the target method under exception and boundary conditions.

[0100] (3) Anomaly and boundary testing tasks

[0101] PromptBundle Data Preparation: Extract information related to exceptions and boundary conditions from the PromptBundle data, including exception declarations of the target method, boundary input values, special scenario examples, etc., while referring to the test class framework in the test class generation task and the test method code generated in the functional test task.

[0102] Model Invocation: Invokes a code generation model specifically designed for exception and boundary condition testing. This model can identify potential anomalies and boundary conditions in the target method and generate corresponding test code to verify the method's behavior under these special circumstances.

[0103] Code snippet generation: The generated test method code snippets contain method declarations for exception and boundary testing, and also follow the naming conventions for test methods; inside the test method, special test data, such as exception input values, boundary values, etc., are constructed, the target method is called and assertion statements are used to verify whether the expected exception is triggered or the correct boundary result is returned.

[0104] Related to other tasks: Exception and boundary testing tasks further improve the functionality of the test class, and together with the code generated by functional testing tasks, they constitute comprehensive test coverage of the target method.

[0105] (4) Coverage optimization task

[0106] PromptBundle Data Preparation: Analyze the existing test code snippets and test result feedback information in the PromptBundle data, including generated test classes, test methods, and coverage reports after test execution, to identify uncovered code branches and lines.

[0107] Model Invocation: Invokes the code generation model used for coverage optimization. This model can generate supplementary test code that improves test coverage based on the characteristics and context information of uncovered code.

[0108] Code snippet generation: The generated test code snippets target uncovered code segments and may include new test methods or supplements to existing test methods. These code snippets can cover previously untouched code paths, thereby improving overall test coverage.

[0109] Related to other tasks: Coverage optimization tasks complement and improve upon all previous testing tasks by generating additional test code to ensure that the test classes fully cover the target code.

[0110] Furthermore, through the agent, based on the PromptBundle data corresponding to different test subtasks, after calling the dedicated test code generation model for each test subtask to generate unit test code snippets for each test subtask, the overall quality score of the unit test code snippets for each test subtask can be calculated. When the overall quality score of the unit test code snippets for each test subtask is lower than the score threshold, a supplementary retrieval strategy is used to retrieve a set of historical test case samples from the historical test case database for the target project code file. Based on the supplemented historical test case sample set and the structured context data of the target project code file, the unit test code snippets for each test subtask are regenerated. The supplementary retrieval strategy includes, but is not limited to, at least one of: expanding the retrieval scope, changing the embedding model, and patterned retrieval. Expanding the retrieval scope can be achieved by increasing the number of candidate samples K, for example, by introducing a new retrieval scope. K represents the initial number of historical test case samples returned when retrieving from the historical test case database. That is, the K historical test case samples that are most similar to the structured context feature vector of the target project code file are initially retrieved from the historical test case database. This is the upper limit set for the number of search results, used to prevent the number of returned samples from increasing indefinitely when the search scope is expanded; changing the embedding model can be done by switching to an embedding model with a larger parameter scale, re-extracting the structured context feature vector, and then performing coverage-weighted similarity retrieval to improve the semantic expressiveness of the retrieval; patterned retrieval can be done by using patterned methods such as text filtering to filter historical test case samples that are more relevant to the target project code file, for example, filtering code snippets containing specific annotations (such as @Test) or method signatures through regular expressions.

[0111] In this embodiment of the application, when integrating unit test code snippets corresponding to different test subtasks into candidate unit test code corresponding to the target project code file, the following methods may be used, but are not limited to:

[0112] The candidate unit test code corresponding to the target project code file is obtained by voting and merging the unit test code snippets corresponding to different test subtasks and performing static syntax completion.

[0113] In this embodiment of the application, when iterating and performing local execution verification and closed-loop feedback updates on the candidate unit test code, the following methods may be used, but are not limited to:

[0114] The candidate unit test code is locally compiled, locally run, and global line coverage is collected and processed to obtain code execution logs and global line coverage.

[0115] Local runtime feedback data for generating candidate unit test code based on code execution logs and global line coverage;

[0116] When it is determined that the local running feedback data does not meet the preset quality standards, the local running feedback data is fed back into the Prompt template corresponding to different test subtasks to be refilled and the updated PromptBundle data corresponding to different test subtasks is obtained.

[0117] Updated candidate unit test code is generated based on the updated PromptBundle data corresponding to different test subtasks.

[0118] In this embodiment, the Prompt templates for different test subtasks are defined using a parameterized approach, supporting dynamic interpolation and replacement of placeholders. By defining placeholders such as {{compileError}}, {{stackTrace}}, and {{missLines}}, error context information is automatically injected after each test failure, enabling targeted repair prompts without manual intervention. Furthermore, each "failure-repair" process is recorded as a mapping pair between the failure stack and the repaired code (failure-patchpair). Within a preset time window, this mapping sample is distilled offline to generate a lightweight repair model (LoRA plugin) for the specific task. In subsequent runs, if the same error type is detected, the Agent will directly call the corresponding LoRA plugin or lightweight model for rapid repair, thereby avoiding re-entering the large model Re-Prompt process and significantly reducing token consumption and generation latency.

[0119] In this embodiment, a coverage-weighted similarity retrieval algorithm is used to prioritize the recall of historical samples with high coverage and semantic similarity. The Prompt example itself has high coverage characteristics, which improves the average line coverage and boundary / abnormal test case hit rate of the generated intermediate test code, thereby significantly improving the coverage and accuracy of the unit test code. The Agent intelligent agent automatically re-feeds back failure / coverage information based on local runtime logs and coverage reports, iteratively updates the PromptBundle and regenerates it until the test code problem information is within the set fault tolerance range. The entire process requires no manual modification of assertions or import statements, achieving efficient generation. -Verification-Optimization of the entire closed loop reduces the cost of manual intervention and effectively improves test development efficiency; by breaking down test class skeletons, normal paths, exception boundaries, and coverage supplementation into independent sub-tasks and calling the corresponding large models for processing, it can enhance multi-model collaboration and task adaptability, improve test code stability and pass rate, and reduce test code failure rate; moreover, the historical test case database and Agent orchestration layer both support local installation, and historical code vectors, coverage data, and failure logs are kept on the intranet, meeting the compliance requirements of industries such as finance and telecommunications for source code not leaving the domain, and can be compatible with multiple languages ​​and private deployment, ensuring data security.

[0120] Next, the unit test code generation method provided in the embodiments of this application will be described in further detail. Please refer to [link / reference]. Figure 2 As shown in the embodiments of this application, the specific process of the unit test code generation method is as follows:

[0121] S201: Through the PSI (Program Structure Interface) and AST (Abstract Syntax Tree) interfaces provided by the integrated development environment (IDE) plugin, the target project code file is parsed to extract a set of structured meta-information such as class names, method signatures, parameter types, and comment information, and a source code syntax tree is constructed as the source code syntax structure model.

[0122] In this embodiment, the source code is parsed using PSI elements such as PsiClass, PsiMethod, and PsiParameter, and a source code structure model is constructed using a symbol table. The symbol table is built based on the abstract syntax tree to extract meta-information such as class name, method signature, modifier, and comments (JavaDoc).

[0123] S202: After parsing the structured meta-information set such as class annotations, method signatures, parameter types and annotation information, as well as the source code syntax structure model such as the source code syntax tree, to obtain structured context data, preprocessing is performed, specifically including: code segmentation, lexicalization, dependency extraction, and storage as a structured context object.

[0124] In this embodiment, the CoverageSuitesManager is called to obtain the current code coverage matrix, construct a dependency graph, and extract the Maven / Gradle dependency tree. This data is then combined with class annotations, dependency relationships, and existing test coverage to form structured context data. A static dependency resolver, combined with the IntelliJ Coverage API, abstracts this structured context data into a serializable JSON object.

[0125] S203: Employs an embedding model-based large-scale encoder (such as a Transformer-based encoder) to vectorize the source code syntax structure model and structured context data. This transforms source code fragments from the syntax structure model and context information from the structured context data into fixed-length dense vectors, serving as the structured context feature vectors of the target project code file. Based on these structured context feature vectors, a similarity retrieval process is performed in a historical test case database to obtain a set of historical test case samples for the target project code file. Specifically, historical test case samples, their structured context feature vectors, and global line coverage are stored in a local or remote historical test case database (such as Milvus / Faiss). The structured context feature vectors of the historical test case samples are generated using an embedding model-based large-scale encoder.

[0126] In this embodiment, a large model encoder is used to embed source code fragments from the source code syntax structure model and context information from the structured context data into a dense vector, which serves as the structured context feature vector. Based on this structured context feature vector, similarity retrieval is performed in a historical test case database (such as Milvus / Faiss). Specifically, this includes:

[0127] The similarity between the target project code file and historical test case samples in the historical test case database is calculated using the Approximate Nearest Neighbor (ANN) algorithm, cosine similarity algorithm, Euclidean distance algorithm, or a hybrid similarity algorithm. Taking the hybrid similarity algorithm as an example, the formula for calculating hybrid similarity is shown below:

[0128]

[0129]

[0130] Where 'a' is the structured context feature vector of the target project code file, and 'b' is the structured context feature vector of historical test case samples in the historical test case database. The cosine similarity is calculated between the structured context feature vector of the target project code file and the structured context feature vector of historical test case samples in the historical test case database. This measures the similarity between the target project code file and historical test case samples in the historical test case database. and These are weighted parameters.

[0131] A coverage-weighted similarity algorithm is used to calculate the coverage-weighted similarity between the target project code file and the historical test case samples in the historical test case database, based on the global line coverage of historical test case samples in the historical test case database and the code similarity between the target project code file and the historical test case samples in the historical test case database. An example of the coverage-weighted similarity calculation formula is as follows:

[0132]

[0133] in, Weighted similarity of global row coverage of historical test case samples in the historical test case database; The maximum global row coverage among all historical test case samples contained in the historical test case database; The similarity between the target project code file and historical test case samples in the historical test case database; and These are weighted parameters.

[0134] In this embodiment, weight factors are dynamically generated during vector recall and priority scheduling, and weighting parameters are dynamically generated based on the weight factors. and The weighting factors are dynamically generated by comprehensively considering multiple dimensions of indicators, including code defect density, execution time, change frequency, and coverage gain. Specifically, they include:

[0135] The weighting factor for each historical test case sample in the historical test case database is calculated using a normalized weighted model. For example, the normalized weighted model could be:

[0136] Wi = α1Di + α2Ti + α3Fi + α4Ci

[0137] Where Wi represents the weight factor of the i-th historical test case sample, Di represents the defect density of the i-th historical test case sample, Ti represents the execution time of the i-th historical test case sample, Fi represents the change frequency of the i-th historical test case sample, Ci represents the coverage gain of the i-th historical test case sample, and α1, α2, α3, and α4 are dynamically adjusted weight coefficients used to balance the influence of various indicators on the weight factor Wi. Based on this normalized weighted model, multi-objective optimal recall is achieved when retrieving similar samples and scheduling generation tasks, effectively improving the relevance of test samples and resource utilization.

[0138] The weight factor Wi of each historical test case sample in the historical test case database is normalized so that its value ranges between [0,1], which facilitates subsequent weight allocation.

[0139] Obtain the initial value ranges of the weighting parameters γ and θ. For example, the initial value range of γ can be set to [0.3, 0.7], and the initial value range of θ can be set to [0.3, 0.7], satisfying γ + θ = 1;

[0140] Calculate the average weight factor Wi of each historical test case sample in the historical test case database. ;

[0141] According to the average The weighting parameters γ and θ are dynamically adjusted based on the relationship between the first threshold T1 and the second threshold T2; wherein the first threshold T1 is greater than the second threshold T2. If If the overall sample quality is high, the value of γ can be appropriately increased and the value of θ decreased, so that the similarity calculation focuses more on the similarity of engineering codes; conversely, if... If θ is increased and γ is decreased, the similarity calculation will place more emphasis on coverage-weighted similarity; if Then, the weighting parameters γ and θ are both set to 0.5 to ensure that the engineering code similarity and global line coverage have the same weight in the global line coverage weighted similarity calculation. This allows the final global line coverage weighted similarity result to simultaneously reflect the semantic similarity and coverage information of the code, thereby more comprehensively evaluating the relevance of the test samples. For example, if Then set γ to 0.6 and θ to 0.4; if Then set γ to 0.4 and θ to 0.6; if Then set γ to 0.5 and θ to 0.5.

[0142] S204: Obtain additional constraint information input by the developer, and fill the structured context data of the target project code file, the historical test case sample set, and the additional constraint information into the Prompt template corresponding to different test subtasks to obtain the PromptBundle data corresponding to different test subtasks; among them, the Prompt template supports interpolation placeholder replacement.

[0143] In this embodiment, the Prompt template is defined using parameters, supporting dynamic replacement of placeholders such as {classContent}, {methodName}, and {dependencies}, to facilitate flexible expansion under different testing scenarios and support multiple scenarios (full class / single method / Mock generation, etc.). Furthermore, failed tests can be further optimized through Prompt iteration (Re-Prompting).

[0144] S205: When generating unit test code, a multi-channel large model request mechanism is used to dynamically select a proxy or direct connection channel based on the network environment, submit requests to the large language model and obtain responses, thereby obtaining unit test code fragments that cannot be returned by the large language model.

[0145] In this embodiment, not only is multi-stage reasoning and sub-task scheduling supported by the Agent intelligent agent framework, but it also supports the Agent intelligent agent in calling large language models dedicated to different sub-tasks to generate unit test code snippets during multi-stage reasoning and task scheduling. This realizes that the Agent intelligent agent framework can perform multi-round reasoning, planning, and test code generation through chained calls and task decomposition. Specifically, the Agent intelligent agent, as a task decomposition and orchestration unit, has the following functions:

[0146] (1) Task breakdown:

[0147] Based on the structured context data of the input target project code file and the historical test case sample set, the agent automatically breaks down the test code generation task for the target project code file into multiple sub-tasks, for example:

[0148] Subtask 1: Generate test class structure and import packages;

[0149] Subtask 2: Generate test cases for the target method;

[0150] Subtask 3: Generate abnormal scenarios and boundary conditions;

[0151] Subtask 4: Verify coverage requirements and optimize test logic.

[0152] (2) Multi-model scheduling:

[0153] After the agent dynamically selects and generates unit test code snippets from large language models dedicated to different subtasks, candidate unit test codes are formed through model voting or fusion mechanisms.

[0154] (3) Vector retrieval combined:

[0155] The Agent will fill the Prompt template with the highly similar historical test case samples retrieved from S203 and the structured context data of the target project code file to ensure that the output code is transferable and context-related. If the coverage of historical fragments is low, the Agent will automatically trigger a supplementary retrieval strategy to add new similar fragments.

[0156] (4) Feedback iteration:

[0157] After receiving the execution logs returned by the IDE or CI, the Agent performs a loop of optimizations: if compilation fails, it triggers a syntax repair subtask; if coverage is insufficient, it triggers a boundary test case expansion subtask; if tests fail, it triggers an assertion logic repair subtask.

[0158] S206: The AI ​​inference backend output includes test code candidate content and reasoning content. The IDE plugin parses the output results, performs regular expression cleanup, and extracts code snippets. It generates corresponding test code based on different programming languages ​​and writes the generated unit test class files to the test directory through the IDE's virtual file system. At the same time, it automatically completes missing package declarations and import statements by combining dependency relationships and programming environment information.

[0159] S207: Feedback the test code compilation and test execution results, as well as error logs, back to the IDE plugin interface and enter the feedback loop: For tests with compilation errors or execution failures, automatically generate a fixed version of the test and populate the results back into the Prompt template, call the large model or Agent for optimization and iteration until the preset quality standards are met.

[0160] S208: Provides a preview function before generation on the plugin side, showing the candidate unit test code to the developer, and displaying the reasoning explanation in a collapsed area. After the developer confirms, the test code is written to the test directory of the IDE project.

[0161] S209: After writing the unit test, the RunManager calls the Unit Runner to automatically trigger the local IDE test run, and uploads the test file through the CI / CD REST API to trigger the build task. At the same time, the test results are uploaded to the CI / CD pipeline, and the coverage results and logs are fed back to the IDE plugin.

[0162] In this embodiment, after writing the unit test, the RunManager calls the Unit Runner to automatically trigger the local IDE test execution. Simultaneously, the test file is uploaded via the CI / CD REST API, triggering a build task and uploading the test results to the CI / CD pipeline. Coverage detection results and logs are fed back to the IDE plugin. This allows for the statistical analysis of coverage improvement rate, number of fixes, and build time. A coverage-weighted similarity formula is proposed, which is more suitable for test case retrieval than a single cosine similarity. This establishes a seamless data flow between the IDE and CI / CD, enabling the plugin to complete a complete closed loop from file writing to test execution, log feedback, prompt repair, and regeneration. Wherein:

[0163] Coverage improvement rate:

[0164]

[0165] in, Code coverage achieved after executing new test code; This refers to the original code coverage before executing new test code; Coverage improvement rate reflects the percentage improvement in code coverage resulting from the new test code.

[0166] Prompt volume increase rate:

[0167]

[0168] in, The final Prompt length after optimization and iteration represents the complexity or richness of the final generated test code. The length of the initial Prompt, i.e., the length of the initial Prompt used to generate the test code; The Prompt quality improvement rate reflects the percentage increase in content during the generation and optimization process of the Prompt, and can be used to measure the degree of improvement of the Prompt.

[0169] The following provides a more detailed description of the automated test code generation and feedback closed-loop processing of the Agent provided in the embodiments of this application.

[0170] The Agent intelligent agent uses OkHttpClientFactory to construct network requests, dynamically selecting proxy routes or direct routes, and supports both streaming and non-streaming invocation modes. For long-connection scenarios, it supports chunked transfer encoding and automatic retry mechanisms. Furthermore, it not only supports multi-stage inference and task scheduling through the Agent intelligent agent framework, but also supports calling large language models dedicated to different subtasks to generate unit test code snippets. (See [link to relevant documentation]). Figure 3 As shown in the embodiments of this application, the automated test code generation and feedback closed-loop processing process for the Agent intelligent agent is as follows:

[0171] S301: Receives the test code generation task for the target project code file and the structured context feature vector (Input ingestion) of the target project code file.

[0172] S302: Vector Retrieval (Local Vector DB): Uses the vector representation of classContent / methodContent as a query to retrieve the most similar historical test case samples (k samples returned).

[0173] Embedding can be performed using a local historical test case database (such as Milvus, Faiss, Qdrant, Chroma, etc.) or an embedding service (local / private Embedding Model).

[0174] Embedding process: v q =Encoder.encode(methodContent); where encoder can be an open-source model or a cloud embedding.

[0175] Retrieve the top K (e.g., K=8) most similar historical test case samples S={S1,S2,...,S...} from the historical test case database. K Similarity calculation can use coverage-weighted similarity, specifically including:

[0176] Calculate cosine similarity:

[0177]

[0178] Calculate mixed similarity (which can be used to enhance retrieval):

[0179]

[0180] The following are examples of weight factor values: .

[0181] After calculating the coverage-weighted similarity, the historical test case sample set returned after similarity recall based on the coverage-weighted similarity is calculated as follows:

[0182]

[0183] Threshold determination and supplementary strategy: When the coverage weighted similarity vecScore of the historical test case sample in the historical test case sample set is less than the similarity threshold Tsim (e.g., 0.6), it is marked as low relevance, and a supplementary retrieval strategy (e.g., expanding K) is triggered to re-retrieve the historical test case sample set.

[0184] S303: Construct PromptBundle data (Prompt Assembly): Construct Prompt fragments or Prompt template instances (i.e., PromptBundle data) corresponding to different subtasks based on the retrieved historical test case sample set and the structured context data of the target project code file.

[0185] Construction Strategy: A list of PromptBundles is created: different PromptBundles are used for different subtasks (e.g., class structure, method testing, exception scenarios, coverage refactoring). Each PromptBundle is injected with the top N (e.g., N=3) historical test case samples retrieved from the historical test case sample set, along with additional constraint information.

[0186] Output: The promptBundles list is given to Task Decomposer / ModelOrchestrator.

[0187] S304: Task Decomposer: The task of generating test code for the target project code file is broken down into several subtasks to facilitate parallelism and division of labor (which can be handled by different models or agents). The TaskDecomposer determines the concurrency granularity based on the AST (number of PsiMethods, complexity metrics such as cyclomatic complexity). The decomposition rules are as follows:

[0188] If scope=class:

[0189] Subtask A: Generates the test class skeleton (imports, class header);

[0190] Subtask B_i: Generates test cases for each public method in the class (in parallel);

[0191] Subtask C: Generates a set of exception / boundary test cases;

[0192] Subtask D: Organize and merge all sub-results.

[0193] If scope=method:

[0194] Subtask B: Generates test cases for this method;

[0195] Subtask C: Generates negative instances / abnormal paths.

[0196] S305: Subtasks are assigned to the backend (single model or agent), and the dedicated test code generation models for each subtask are scheduled in parallel to obtain multiple unit test code snippets and their confidence scores output by each subtask-specific test code generation model; wherein, each subtask-specific test code generation model is a large language model. Specifically, this includes:

[0197] (1) Scheduling strategy: Select a dedicated test code generation model for different subtasks:

[0198] Structure / template-based tasks: Test code generation models with strong formatting capabilities;

[0199] Coverage Improvement / Complex Logic: A test code generation model with strong logical reasoning and problem-solving capabilities;

[0200] Multi-round planning / error correction: A test code generation model with strong cyclical correction capabilities.

[0201] (2) Support parallel execution: Submit multiple requests using thread pools or coroutine pools and merge response waiting windows (e.g., 30s).

[0202] (3) Timeout / Degradation: Retry after the request times out (e.g., at most once), and if it fails, downgrade to the backup model or return part of the result and record the error.

[0203] (4) Supplementary search (S305A): If the test code generation model returns a low confidence score or the generated unit test code snippet differs significantly from the structured context of the target project code file (cosine similarity or model confidence score < threshold), then supplementary search is triggered: increase K, use different embeddings, or use patterned search (based on text filtering).

[0204] In this embodiment of the application, after scheduling the dedicated test code generation model for each subtask and obtaining multiple unit test code snippets and their confidence levels output by the dedicated test code generation model for each subtask, it is also possible to determine whether supplementary retrieval is needed based on the comprehensive quality score of each unit test code snippet. Specifically, this includes:

[0205] (1) The following comprehensive quality scoring model is used to calculate the comprehensive quality score (Score) for each unit test code segment:

[0206]

[0207] Among them, Conf model The confidence level (0~1) of a unit test code snippet is used. If the test code generation model outputs a logits vector (representing the predicted score for each category) or probability distribution parameters, then logits or temperature estimation can be used to calculate the confidence level of the unit test code snippet. retrieval EstCoverage represents the cosine similarity (0~1) between the structured context feature vectors of the unit test code snippet calculated by the cosine similarity algorithm and the target project code file; EstCoverage represents the coverage estimate (0~1) of the unit test code snippet estimated using static analysis or lightweight fuzzing. , , As weighted parameters, they can be adjusted through small-scale A / B experiments or Bayesian optimization, for example... .

[0208] (2) When the overall quality score of unit test code segments is less than the score threshold Tconf for at least 80% of the unit test code segments, a supplementary retrieval strategy is executed:

[0209] Add retrieval K'=min(K 2, Kmax);

[0210] Use a different embedding model for retrieval;

[0211] Merge the new sample into Prompt and retry.

[0212] S306: Result Aggregation and Fusion (Fusion Engine): Employs a voting fusion strategy to integrate the unit test code snippets output by multiple test code generation models specific to different test subtasks to obtain candidate unit test code. Specifically, this includes:

[0213] (1) Pretreatment:

[0214] Obtain the unit test code snippets output by the test code generation model dedicated to multiple test subtasks, and construct an initial set of unit test code snippets.

[0215] The similarity of each unit test code fragment in the initial set of unit test code fragments is identified by calculating the similarity of code syntax structure (such as abstract syntax tree matching degree), semantic similarity (such as cosine similarity after code vectorization), or functional logic similarity analysis (such as the overlap of test targets and called functions). Independent unit test code fragments that do not meet the similarity threshold are retained as unit test code fragments to be voted and sorted. Unit test code fragments that meet the similarity threshold are grouped into the same similar code group.

[0216] For each similar code group, extract the core code (such as test method definition, parameter input, function call logic, etc.) and assertion set (such as assertion statements to verify the behavior of the tested method, exception verification logic, boundary condition checks, return value verification, etc.) of each unit test code snippet in the similar code group. The assertion set is the set of assertion statements in the unit test code snippet used to verify the test results. Perform a union operation on all assertion sets in the similar code group to obtain the merged assertion set of the similar code group. Redundancy removal is performed on the assertion statements in the merged assertion set (such as deleting duplicate assertions that are completely consistent in syntax, logic, and verification objectives) to obtain the deduplicated assertion set. Fill the core code of each unit test code snippet contained in the similar code group with the deduplicated assertion set to obtain the unit test code snippets to be voted and sorted.

[0217] Based on all the unit test code snippets to be voted on and sorted, construct a set of code snippets to be voted on and sorted.

[0218] (2) Voting Integration:

[0219] Calculating the Borda count score: The Borda count method is used to calculate the Borda count score for each unit test code snippet in the set of code snippets to be ranked. In the Borda count method, weights are assigned to the corresponding test code generation models based on their confidence or performance. For each unit test code snippet, based on the weights of each test code generation model, the Borda count score is obtained by weighted summing the confidence ranking scores of the unit test code snippets output by different test code generation models. For example, if there are three test code generation models that output unit test code snippets X, namely model A, model B, and model C, and the confidence ranking of unit test code snippet X is 1 among the N unit test code snippets output by model A, 2 among the M unit test code snippets output by model B, and 1 among the L unit test code snippets output by model C, then the Borda count score of unit test code snippet X can be calculated as: model A weight × (N-1) + model B weight × (M-2) + model C weight × (L-1).

[0220] Calculating the weighted average score: The weighted average method is used to calculate the weighted average score of each unit test code snippet in the set of code snippets to be voted on and ranked. In the weighted average method, each test code generation model is assigned a weight based on its confidence or performance. For each unit test code snippet, the weighted average score is obtained by weighting the confidence scores of the unit test code snippet in different test code generation models. For example, the weight of test code generation model A is 0.4, the weight of test code generation model B is 0.3, and the weight of test code generation model C is 0.3. For unit test code snippet X, its confidence scores in test code generation models A, B, and C are 80, 70, and 90, respectively. Then the weighted average score of unit test code snippet X can be calculated as: 0.4 × 80 + 0.3 × 70 + 0.3 × 90 = 79.

[0221] The combined sorting based on Borda count score and weighted average score is as follows: For each unit test code segment, the Borda count score and the weighted average score of the unit test code segment are weighted and summed to obtain the final score of the unit test code segment; the unit test code segments are sorted based on the final score to obtain a final sorting result that takes into account both Borda count sorting and weighted average sorting.

[0222] (3) Optimize output:

[0223] Assertion merging: Semantic analysis techniques are used to compare assertions in the various unit test code snippets included in the final ranking result. Similar assertions with similar verification purposes or similar logical structures are identified and merged to obtain a merged assertion set. This step can reduce duplicate assertions and improve the conciseness and readability of the test code.

[0224] Assertion optimization: Optimizing the merged assertion set yields an optimized assertion set, improving the accuracy and efficiency of synthesized assertions. This optimization process may include removing redundant assertions and simplifying complex assertion logic. Specifically, this includes: examining the logic and implementation of each assertion; directly deleting redundant assertions; and simplifying and refactoring complex assertion logic to improve execution efficiency and maintainability.

[0225] Fusion Output: Based on the final ranking result and the optimized assertion set, candidate unit test code is generated. Specifically, this involves filling the core code of each unit test code snippet within the final ranking result with the optimized assertion set to obtain the candidate unit test code. This candidate unit test code combines the advantages of multiple test code generation models, resulting in higher quality and reliability.

[0226] (4) Verification and evaluation:

[0227] Verify and evaluate candidate unit test code to ensure it meets testing requirements and effectively improves test coverage. Verification and evaluation may include syntax checking, semantic analysis, coverage evaluation, and other aspects.

[0228] S307: Post-processing (code extraction, cleaning, and completion): Extract pure Java / Go / Python / C++ code from candidate unit test code, remove Markdown / description text, automatically complete import / package, and perform syntax verification and minimal syntax repair using AST. A safety belt strategy is used for automatic repair: only low-risk changes are made (such as adding semicolons or imports), and complex repairs require manual confirmation.

[0229] S308: Local Static Validation / Compilation / Fast Execution (Validator): Compiles and runs unit tests in a local temporary environment (or an in-memory project in the IDE) (or uses a fast simulator), collects compilation logs, execution results, and coverage information, and writes the files to src / test / java / ... (or to a temporary directory and runs using Maven / Gradle commands). Specifically, it includes:

[0230] Compile the source code (or mvn -DskipTests=false -Dtest=...test-q);

[0231] Run XUnit (can be limited to a single test class or method);

[0232] Collect coverage (or IntelliJ coverage API);

[0233] Time budget: To avoid CI timeout, a local verification timeout is preset (e.g., 60 seconds).

[0234] S309: Feedback Decision and Iteration / Termination (Feedback Loop): During test code generation, the feedback loop mechanism determines whether to terminate or proceed to the next iteration based on the validation results of the validator. This process follows these rules and strategies:

[0235] (1) Termination condition:

[0236] The test code generation process is considered to have reached its termination condition if and only if the following conditions are met simultaneously:

[0237] Compilation successful (compileOk): The generated candidate unit test code compiles successfully without syntax errors;

[0238] Test Pass: The generated candidate unit test code executed successfully and passed all preset test cases;

[0239] Coverage rate met (coverage) coverageThreshold: The coverage of candidate unit test code reaches a preset threshold (e.g., coverageThreshold is 0.8), ensuring that the coverage of the target code by the candidate unit test code meets the quality requirements.

[0240] (2) Iteration limit:

[0241] To avoid infinite loops, a maximum number of iterations is preset (maxIterations, for example, set to 3). If the termination condition is not met after reaching the maximum number of iterations, the system will automatically terminate the generation process.

[0242] (3) Failure feedback and prompts:

[0243] If the verification result indicates that the currently generated test code fails verification (i.e., the termination condition is not met), the system will construct detailed feedback payload. This feedback payload includes key data such as error logs, stack traces, and uncovered lines of code.

[0244] The feedback payload is then populated back into the Prompt template, triggering a new round of iterative optimization. This mechanism ensures that the model can be improved in a targeted manner based on precise feedback information.

[0245] (4) Stopping strategy:

[0246] If test code meeting the requirements is not successfully generated after reaching the maximum number of iterations (maxIterations), the current result is marked as requiring manual review. At this point, the IDE will highlight the reason for the failure and the generated model in a prominent manner (e.g., marked in red) to prompt developers to intervene and review the code manually.

[0247] Based on the above embodiments, this application provides a unit test code generation system, see below. Figure 4 As shown, the unit test code generation system 400 provided in this application embodiment includes at least:

[0248] The source code parsing module 401 is used to perform program structure interface parsing and abstract syntax tree parsing on the target project code file to obtain a set of structured meta-information and a source code syntax structure model;

[0249] The feature extraction module 402 is used to determine the structured context data of the target project code file based on the structured meta-information set and the source code syntax structure model, and to vectorize the structured context data to obtain the structured context feature vector of the target project code file.

[0250] The historical retrieval module 403 is used to retrieve historical test case samples from the historical test case database that meet the matching condition of the global row coverage weighted similarity of the structured context feature vector of the target project code file, using a coverage weighted similarity retrieval algorithm. The historical test case database includes each historical test case sample and the corresponding structured context feature vector and global row coverage of each historical test case sample.

[0251] The code generation module 404 is used to determine the various test subtasks corresponding to the target project code file based on the structured context data and historical test case sample set of the target project code file through the agent intelligent agent. Based on the historical test case sample set and structured context data, it fills the Prompt templates corresponding to different test subtasks to obtain PromptBundle data corresponding to different test subtasks. Based on the PromptBundle data corresponding to different test subtasks, it calls the test code generation model dedicated to different test subtasks to generate unit test code snippets corresponding to different test subtasks. It integrates the unit test code snippets corresponding to different test subtasks into candidate unit test code corresponding to the target project code file. It iterates and performs local running verification and closed-loop feedback updates on the candidate unit test code until it meets the preset quality standards. Then, it determines the last updated candidate unit test code as the final unit test code.

[0252] In one possible implementation, the feature extraction module 402 is used to call CoverageSuitesManager to obtain the current coverage engine data; for each method in the structured meta information set, it calls fileName+startLine / endLine to collect the row-level coverage array based on the current coverage engine data, and calculates the method-level coverage index based on the row-level coverage array, and then writes the row-level coverage array and the method-level coverage index back to the corresponding node in the structured meta information set to obtain the structured context data.

[0253] In one possible implementation, the history retrieval module 403 is used to calculate the engineering code similarity between the target engineering code file and each historical test case sample based on the structured context feature vector of the target engineering code file and the structured context feature vector of each historical test case sample in the historical test case database; calculate the global line coverage weighted similarity between the target engineering code file and each historical test case sample based on the engineering code similarity between the target engineering code file and each historical test case sample and the global line coverage of each historical test case sample; and select historical test case samples from each historical test case sample whose global line coverage weighted similarity meets the matching condition to form a historical test case sample set.

[0254] In one possible implementation, the history retrieval module 403 is further configured to, based on a supplementary retrieval strategy, supplement the historical test case sample set of the target project code file from the historical test case database when the global line coverage of each historical test case sample in the historical test case sample set is lower than the coverage threshold, or when the comprehensive quality score of the unit test code fragments corresponding to different test subtasks is lower than the score threshold; and regenerate the unit test code fragments corresponding to different test subtasks based on the supplemented historical test case sample set and the structured context data of the target project code file.

[0255] In one possible implementation, the code generation module 404 is used to extract key code portions that match the business logic and test requirements of the target project code file from each historical test case sample in the historical test case sample set; adapt and integrate the key code portions that match the business logic and test requirements of the target project code file according to the structure and semantics of the target project code file to obtain historical test case fragments that match the target project code file; and fill the historical test case fragments and structured context data into the corresponding placeholders in the Prompt templates corresponding to different test subtasks to obtain PromptBundle data corresponding to different test subtasks.

[0256] In one possible implementation, the code generation module 404 is used to perform voting fusion and static syntax completion on the unit test code fragments corresponding to different test subtasks to obtain candidate unit test code corresponding to the target project code file.

[0257] In one possible implementation, the code generation module 404 is used to perform local compilation, local execution, and global line coverage collection processing on the candidate unit test code to obtain code execution logs and global line coverage; generate local execution feedback data of the candidate unit test code based on the code execution logs and global line coverage; when it is determined that the local execution feedback data does not meet the preset quality standards, the local execution feedback data is fed back into the Prompt templates corresponding to different test subtasks for re-population to obtain updated PromptBundle data corresponding to different test subtasks; and generate updated candidate unit test code based on the updated PromptBundle data corresponding to different test subtasks.

[0258] It should be noted that the principle of the unit test code generation system 400 provided in this application embodiment to solve the technical problem is similar to that of the unit test code generation method provided in this application embodiment. Therefore, the implementation of the unit test code generation system 400 provided in this application embodiment can refer to the implementation of the unit test code generation method provided in this application embodiment, and the repeated parts will not be described again.

[0259] After introducing the unit test code generation method and system provided in the embodiments of this application, the electronic device provided in the embodiments of this application will be briefly introduced next.

[0260] The electronic devices provided in this application embodiment may be, but are not limited to, computers, laptops, servers, etc., see reference. Figure 5 As shown, the electronic device 500 provided in this application embodiment includes at least a processor 501, a memory 502, and a computer program stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program, it implements the unit test code generation method provided in this application embodiment.

[0261] In one possible implementation, memory 502 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 5021 and / or cache memory 5022, and may further include read-only memory (ROM) 5023; memory 502 may also include a program tool 5025 having a set (at least one) of program modules 5024, including but not limited to: operating subsystem, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0262] In one possible implementation, the electronic device 500 provided in this application embodiment may further include a bus 503 connecting different components (including processor 501 and memory 502). The bus 503 represents one or more types of bus structures, including memory bus, peripheral bus, local area bus, etc.

[0263] In one possible implementation, the electronic device 500 can also communicate with one or more devices that enable a user to interact with the electronic device 500 (e.g., mobile phones, computers, etc.), and / or with external devices 504 such as devices that enable the electronic device 500 to communicate with one or more other electronic devices 500 (e.g., routers, modems, etc.). This communication can be performed via an input / output (I / O) interface 505. Furthermore, the electronic device 500 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 506. Figure 5 As shown, network adapter 506 communicates with other modules of electronic device 500 via bus 503. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0264] It should be noted that, Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0265] Furthermore, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the unit test code generation method described above in embodiments of this application. Specifically, the computer instructions may be built into or installed in a processor, enabling the processor to implement the unit test code generation method described above in embodiments of this application by executing the built-in or installed computer instructions.

[0266] Of course, the unit test code generation method provided in the embodiments of this application can also be implemented as a program product, which includes program code. When the program code is executed by a processor, it implements the unit test code generation method provided in the embodiments of this application.

[0267] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0268] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method of generating unit test code, characterized by, Applied to the rhinoceros performance platform, comprising: The target engineering code file is parsed to obtain a structured meta-information set and a source code syntax structure model, and the structured context data of the target engineering code file is determined based on the structured meta-information set and the source code syntax structure model, and the structured context feature vector of the target engineering code file is obtained by vectorizing the structured context data; The coverage weighted similarity retrieval algorithm is used to retrieve the historical test case sample set from the historical test case database, wherein the historical test case database includes each historical test case sample, and each historical test case sample corresponds to a structured context feature vector and a global line coverage rate; Through the Agent intelligent agent, the structured context data of the target engineering code file and the historical test case sample set are determined, the Prompt template corresponding to different test sub-tasks is filled based on the historical test case sample set and the structured context data, the PromptBundle data corresponding to different test sub-tasks is obtained, the test code generation model dedicated to different test sub-tasks is called based on the PromptBundle data corresponding to different test sub-tasks, and the unit test code segment corresponding to different test sub-tasks is integrated into the candidate unit test code corresponding to the target engineering code file. The coverage weighted similarity retrieval algorithm is used to retrieve the historical test case sample set from the historical test case database, wherein the historical test case database includes each historical test case sample, and each historical test case sample corresponds to a structured context feature vector and a global line coverage rate; Based on the structured context feature vector of the target engineering code file and the structured context feature vector of each historical test case sample in the historical test case database, the engineering code similarity between the target engineering code file and each historical test case sample is calculated; Based on the engineering code similarity between the target engineering code file and each historical test case sample and the global line coverage rate of each historical test case sample, the global line coverage rate weighted similarity between the target engineering code file and each historical test case sample is calculated; The historical test case sample set is selected from each historical test case sample, and the global line coverage rate weighted similarity of the historical test case sample set is matched.

2. The unit test code generation method of claim 1, wherein, Based on the structured meta-information set and the source code syntax structure model, the structured context data is determined, comprising: Call CoverageSuitesManager to obtain current coverage engine data; For each method in the structured meta-information set, call a fileName+startLine / endLine collection line-level coverage array based on the current coverage engine data, and after calculating the method-level coverage indicators based on the line-level coverage array, write the line-level coverage array and the method-level coverage indicators back to the corresponding node in the structured meta-information set to obtain structured context data.

3. The unit test code generation method of claim 1, wherein, Also includes: When the global line coverage of each historical test case sample in the historical test case sample set is lower than the coverage threshold, or when the comprehensive quality score of the unit test code segment corresponding to the different test sub-tasks is lower than the score threshold, the historical test case sample set of the target engineering code file is supplemented from the historical test case database based on the supplementary retrieval strategy; Based on the historical test case sample set after supplementary retrieval and the structured context data of the target engineering code file, the unit test code segment corresponding to the different test sub-tasks is regenerated.

4. The unit test code generation method of claim 1, wherein, Based on the historical test case sample set and the structured context data, the Prompt template corresponding to the different test sub-tasks is filled to obtain the PromptBundle data corresponding to the different test sub-tasks, including: From each historical test case sample in the historical test case sample set, extract the key code part that matches the business logic and test requirements of the target engineering code file; Adapt and integrate the key code part in each historical test case sample that matches the business logic and test requirements of the target engineering code file according to the structure and semantics of the target engineering code file to obtain a historical test case fragment that matches the target engineering code file; Fill the historical test case fragment and the structured context data into the corresponding placeholders in the Prompt template corresponding to the different test sub-tasks to obtain the PromptBundle data corresponding to the different test sub-tasks.

5. The unit test code generation method of claim 1, wherein, Integrate the unit test code segments corresponding to the different test sub-tasks into the candidate unit test code corresponding to the target engineering code file, including: Perform voting fusion and static syntax completion processing on the unit test code segments corresponding to the different test sub-tasks to obtain the candidate unit test code corresponding to the target engineering code file.

6. The unit test code generation method according to any one of claims 1 to 5, wherein, Local running verification and closed-loop feedback update on the candidate unit test code, including: Local compilation, local running and global line coverage collection processing on the candidate unit test code to obtain code execution logs and global line coverage; Based on the code execution logs and the global line coverage, generate local running feedback data for the candidate unit test code; When the local running feedback data does not meet the preset quality standard, backfill the local running feedback data into the Prompt template corresponding to the different test sub-tasks to obtain updated PromptBundle data corresponding to the different test sub-tasks; The updated candidate unit test code is generated based on the updated PromptBundle data corresponding to different test sub-tasks.

7. A unit test code generation system characterized by comprising: The application is applied to a rhinoceros performance platform, and comprises: A source code parsing module is configured to perform program structure interface parsing and abstract syntax tree parsing on a target engineering code file to obtain a structured meta-information set and a source code syntax structure model. A feature extraction module is configured to determine structured context data of the target engineering code file based on the structured meta-information set and the source code syntax structure model, and to obtain a structured context feature vector of the target engineering code file by vectorizing the structured context data. A history retrieval module is configured to search, by using a coverage weighted similarity retrieval algorithm, a historical test case sample set from a historical test case database, wherein the historical test case sample set comprises historical test case samples that satisfy a matching condition in terms of global line coverage weighted similarity with the structured context feature vector of the target engineering code file. A code generation module is configured to determine, by using an Agent intelligent agent, each test sub-task corresponding to the target engineering code file based on the structured context data of the target engineering code file and the historical test case sample set, to obtain PromptBundle data corresponding to different test sub-tasks by filling Prompt templates corresponding to the different test sub-tasks based on the historical test case sample set and the structured context data, to generate unit test code segments corresponding to different test sub-tasks by calling test code generation models corresponding to the different test sub-tasks based on the PromptBundle data corresponding to the different test sub-tasks, to integrate the unit test code segments corresponding to the different test sub-tasks into candidate unit test code corresponding to the target engineering code file, and to iteratively perform local running verification and closed-loop feedback updating on the candidate unit test code until a preset quality standard is satisfied, and to determine the candidate unit test code updated for the last time as final unit test code. The history retrieval module is configured to calculate engineering code similarity between the target engineering code file and each historical test case sample based on the structured context feature vector of the target engineering code file and the structured context feature vector of each historical test case sample in the historical test case database, to calculate global line coverage weighted similarity between the target engineering code file and each historical test case sample based on the engineering code similarity between the target engineering code file and each historical test case sample and the global line coverage of each historical test case sample, and to select historical test case samples that satisfy a matching condition in terms of global line coverage weighted similarity from each historical test case sample to form the historical test case sample set.

8. An electronic device, comprising: A computer program product comprising a computer readable storage medium having computer program code embodied therewith, the computer program code configured such that, on execution by a computer, the computer is caused to perform the method of any of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are executed by the processor to implement the unit test code generation method of any of claims 1-6.

Images