Unit test code generation method based on large language model, and related device

Abstract

Provided in the embodiments of the present disclosure are a unit test code generation method based on a large language model, and a related device. In the embodiments of the present disclosure, a large language model is invoked by means of a unit test agent to generate in batches unit test codes corresponding to a plurality of test functions in a plurality of different test scenarios, a compiler is invoked by means of the unit test agent to automatically compile the unit test codes generated by the large language model, and a construction tool is invoked by means of the unit test agent to automatically run the compiled unit test codes, thus realizing the automatic generation, automatic compilation and automatic running of unit test codes, and realizing the batch generation of unit test codes which covers various and diverse test scenarios, thereby improving test coverage, increasing the success rate of acquiring successfully run unit test codes, improving the accuracy and availability of the unit test codes, greatly reducing the time consumption and maintenance costs of developers in unit test scenarios, and improving the development efficiency of the unit test codes.

Description

Unit test code generation method and related equipment based on large language models Technical Field

[0001] This disclosure relates to the field of software development technology, and in particular to a method and related equipment for generating unit test code based on a large language model. Background Technology

[0002] Unit testing is a testing method that verifies whether the smallest testable unit of software (such as a function) works as expected. It features isolation, automation, fine-grainedness, and rapid feedback, improving code quality, supporting refactoring, serving as documentation, and facilitating rapid debugging. During software development, unit testing ensures the quality of the source code developed by developers. In practice, developers often write unit test code manually. However, manually written unit test code often has low test coverage; it requires a significant investment of time and effort; and as the source code is continuously updated, the unit test code also needs frequent modification and maintenance, resulting in high maintenance costs. Summary of the Invention

[0003] This disclosure provides a method and related equipment for generating unit test code based on a large language model, which can improve the test coverage of unit test code, reduce the time and effort required to write unit test code, and reduce the maintenance cost of unit test code.

[0004] This disclosure provides a method for generating unit test code based on a large language model, comprising: obtaining the code file under test in the current software project and obtaining multiple target project dependency information required to generate unit test code, wherein the multiple target project dependency information includes at least the identifier of the target simulation framework and the identifier of the target testing framework; analyzing the code file under test and the multiple target project dependency information by calling the large language model through a unit test agent to obtain analysis results, the analysis results including a set of functions under test and an execution plan, and generating unit test code corresponding to each test function in different test scenarios according to the execution plan based on the target simulation framework and the target testing framework; wherein the set of functions under test includes multiple functions under test extracted from the code file under test; the execution plan is used to instruct the sequential generation of unit test code corresponding to each function under test based on the target simulation framework and the target testing framework; compiling the unit test code corresponding to each test function in different test scenarios by calling the compiler through the unit test agent, and calling the build tool to run the compiled unit test code to obtain the successfully run unit test code of each test function in different test scenarios.

[0005] This disclosure provides an electronic device, including: a memory and a processor; the memory being configured to store a computer program; and the processor being coupled to the memory and configured to execute the computer program to perform steps in a unit test code generation method based on a large language model.

[0006] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the processor to implement steps in a unit test code generation method based on a large language model.

[0007] This disclosure provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to implement the steps in a unit test code generation method based on a large language model.

[0008] In this embodiment, a unit test agent calls a large language model to generate unit test code for multiple test functions in multiple different test scenarios. The unit test agent then calls a compiler to automatically compile the unit test code generated by the large language model, and finally calls a build tool to automatically run the compiled unit test code. This achieves automatic generation, compilation, and execution of unit test code, enabling batch generation of unit test code covering various diverse test scenarios. This improves test coverage, increases the success rate of obtaining successfully executed unit test code, enhances the accuracy and usability of unit test code, significantly reduces the time and maintenance costs for developers in unit test scenarios, and improves the development efficiency and code quality of unit test code. Attached Figure Description

[0009] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0010] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of this disclosure;

[0011] Figure 2 is a flowchart of a unit test code generation method based on a large language model provided in an embodiment of this disclosure;

[0012] Figure 3 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0013] Figure 4 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0014] Figure 5 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0015] Figure 6 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0016] Figure 7 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0017] Figure 8 is a schematic diagram of an interface provided in an embodiment of this disclosure;

[0018] Figure 9 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0020] In the embodiments of this disclosure, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the textual description of this disclosure, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship. Furthermore, in the embodiments of this disclosure, "first," "second," "third," etc., are only used to distinguish the content of different objects and have no other special meaning.

[0021] The following is an explanation of some of the terms used in this disclosure.

[0022] AI Agent: A software or hardware entity that has the ability to autonomously perceive its environment, make decisions, and execute actions, with the aim of completing specific tasks or achieving goals in the simulated or real world.

[0023] Compiler (compiling program): A software program that translates a source program (high-level language) into a target program.

[0024] Build tool: A type of automated software that assists in the execution of code.

[0025] Large Language Models (LLMs): LLMs are typically based on deep learning architectures, especially the Transformer architecture. They learn the complex structures and rich contextual information of language through pre-training on massive amounts of text data. LLMs can handle various natural language tasks, such as text classification, question answering, and dialogue, and are an important pathway to artificial intelligence. The Transformer module is a neural network structure based on a self-attention mechanism, which significantly improves model performance through parallel processing and self-attention.

[0026] A software project typically refers to a collection of related code files, library files, and resource files that together constitute a part of a complete software application or system. A software project usually includes: a source code directory, a library file directory, a resource file directory, and a test code directory. The source code directory stores all source code files. The library file directory stores third-party libraries that the project depends on. The resource file directory stores non-code resources such as configuration files and images. The test code directory stores test code files.

[0027] A mocking framework is a tool used to simulate the behavior of external dependencies or complex objects during testing. It allows developers to create "mock objects" that can replace real objects or services, thereby isolating the code under test and ensuring the independence and reliability of the tests.

[0028] A testing framework is a set of tools and libraries for writing, executing, and managing test code. It provides developers with a structured environment that makes writing, running, and maintaining tests simpler and more efficient. Testing frameworks typically include features such as automated test execution, test result reporting, and test coverage analysis, helping development teams ensure code quality, stability, and maintainability.

[0029] Unit testing is a testing method that verifies whether the smallest testable unit of software (such as a function) works as expected. It features isolation, automation, fine-grainedness, and rapid feedback, improving code quality, supporting refactoring, serving as documentation, and facilitating rapid debugging. During software development, unit testing ensures the quality of the source code developed by developers. In practice, developers often write unit test code manually. However, manually written unit test code often has low test coverage; it requires a significant investment of time and effort; and as the source code is continuously updated, the unit test code also needs frequent modification and maintenance, resulting in high maintenance costs.

[0030] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of this disclosure. Referring to Figure 1, developers open a code editor on various terminal devices such as desktop computers, laptops, or tablets, and perform code development work in the code editor with the support of input devices such as keyboards and mice. During code development, developers often use intelligent programming assistance tools installed on the terminal device to assist in the development work. In intelligent coding scenarios, intelligent programming assistance tools based on large language models can provide capabilities such as line-level / function-level real-time continuation coding, natural language code generation, unit test generation, code optimization, comment generation, code explanation, and exception handling, helping developers code efficiently and fluently.

[0031] In practical applications, unit test agents can be deployed in intelligent programming aids. A unit test agent can be understood as an agent with unit testing capabilities. It can invoke a large language model to perform tasks such as code generation and optimization, call a compiler to compile code, and invoke build tools to run code. Of course, unit test agents can also perform many more tasks.

[0032] Specifically, by using a unit test agent to invoke a large language model, developers can improve efficiency in unit testing scenarios. This eliminates the need for developers to manually write unit test code; the large language model automatically generates unit test code covering diverse scenarios. The unit test agent then calls the compiler to automate the compilation of the unit test code, invokes build tools to automate code execution, and uses the large language model for code optimization. It also provides interactive interfaces for execution plan confirmation, automatic code adoption, and code review, enabling developers to leverage artificial intelligence (AI) capabilities to efficiently and smoothly generate unit test code, improving development efficiency and code quality. This is applicable to software engineering of all sizes, and has significant application value, especially in the development of large-scale, complex systems.

[0033] It should be noted that the application scenario shown in Figure 1 is merely an exemplary application scenario, and the embodiments of this disclosure do not limit the application scenario. The embodiments of this disclosure do not limit the devices included in Figure 1, nor do they limit the positional relationship between the devices in Figure 1.

[0034] The technical solutions of this disclosure and how they solve the aforementioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The technical solutions provided by each embodiment of this disclosure are described in detail below with reference to the accompanying drawings.

[0035] Figure 2 is a flowchart of a unit test code generation method based on a large language model provided in an embodiment of this disclosure. Referring to Figure 2, the method may include steps 201 to 203.

[0036] Step 201: Obtain the code file under test in the current software project and obtain the dependency information of multiple target projects required to generate unit test code. The dependency information of multiple target projects includes at least the identifier of the target simulation framework and the identifier of the target test framework.

[0037] Specifically, the current software project refers to any existing software project, and the code file under test can be any code file within the current software project that requires unit testing. The code file under test includes, but is not limited to, source code files and code snippet files. Source code files are complete code files containing the core logic and functionality of the software project. Source code files are typically written by developers and include the project's technical logic, algorithm implementation, class definitions, function definitions, etc. Code snippet files are files containing a small number of code snippets. A code snippet file is not necessarily a complete, compileable program, but rather a code snippet focused on a specific function or problem. A code snippet file can include a few lines of code, a few functions, or a portion of a class.

[0038] In practical applications, there can be one or more code files under test. Understandably, generating corresponding unit test code in batches for multiple code files under test improves unit testing efficiency by processing test requirements for multiple files in batches.

[0039] In practical applications, users can select the code file to be tested from the current software project as needed. The current software project may also contain code change information, which records the changed code. Users can select the changed code file as the code file to be tested. This ensures that unit tests can still be performed on the changed code file after code changes, thereby improving code quality and project stability.

[0040] Based on the above, the implementation method for obtaining the code file under test in the current software project is as follows: The system receives unit test code generation requirement information input by the user for the current software project. This requirement information indicates the identifier of the code file under test or indicates the generation of corresponding unit test code for code changes. If the requirement information indicates the identifier of the code file under test, the system searches for the code file under test in the current software project. If the requirement information indicates the generation of corresponding unit test code for code changes, the system searches for the code changes in the current software project and uses the modified code file involved in the code changes as the code file under test.

[0041] In practical applications, an interactive interface can be provided to users. Users input unit test code for the current software project to generate requirement information on this interface. This interface could be, for example, an AI dialogue interface where users interact with a large language model. Referring to Figure 3, the AI ​​dialogue interface can display an information input area, but is not limited to this. The information input area is primarily used to receive user input; it is typically represented by an input box where users can enter plain text, images, links, and other information. The information input area can include a prompt input area and a context introduction area. The prompt input area can be understood as an input box specifically for entering prompts. Users can enter various input content in natural language form (also called natural language text), images, links, etc., without restriction. For example, the unit test code generation requirement information entered in the prompt input area might be "Use JUnit5 testing to generate unit test code corresponding to OrderServicelmpl.java". JUnit5 testing is a testing framework, and OrderServicelmpl.java is the code file under test.

[0042] The context introduction area can be understood as an input box specifically for entering contextual information. Users can enter the contextual information needed for dialogue interaction with the large language model in the context introduction area. The context introduction area allows users to select one or more files as the context for dialogue interaction at once, reducing the number of user operations and improving the user experience. In practical applications, there are no restrictions on how the file selection operation is triggered in the context introduction area. For example, users can click, double-click, or long-press the context introduction area to trigger the file selection operation; or, as shown in Figure 3, an add control can be displayed in the context introduction area to guide the user to add the control and initiate the file selection operation.

[0043] In practical applications, upon receiving a file selection operation triggered in the context introduction area, the system can retrieve available files based on pre-specified folder paths, storage paths, etc., and display the file identifiers of the available files for the user to select. However, it is not limited to this. In practical applications, the types of available files include, but are not limited to, code files, image files, or code change content from the current software engineering project.

[0044] In practical applications, upon receiving a file selection operation triggered in the context introduction area, a context selection panel can pop up in the interactive interface. This panel displays multiple optional file identifiers for the user to choose from, such as codebase, file, codeChanges, image, OrderServicelmpl.java, OrderService.java, and FileUtil.java. The context selection panel can take various forms, including but not limited to: an interface, a window, or a card. It can also include an input box where the user enters a file identifier. The system then retrieves the file identifier and displays the corresponding file identifier label in the context introduction area. This file identifier label, or tag-style file identifier, enriches the file selection methods.

[0045] In practical applications, the unit test code generation requirement information input by the user for the current software project describes the request information of this dialogue interaction. The unit test code generation requirement information can indicate the identifier of the code file being tested, or it can indicate that the unit test is related to the code changes (codeChanges), that is, to perform unit tests on the changed code file. The changed code file can refer to the file obtained by modifying the source code file. The changed code file includes, but is not limited to, new code added to the source code file, code deleted from the source code file, or modified code in the source code file.

[0046] In some optional embodiments, to ensure that the large language model better understands user needs and improves the reliability of the generated unit test code, the unit test code generation requirement information may further include: an identifier of the context information of the code file under test. For example, referring to Figure 3, the user selects the context information of the code file under test in the pop-up context selection panel; the codebase file and the OrderServicelmpl.java file are selected as context information. When the send button in the prompt input area is clicked, the user receives the unit test code generation requirement information input in the prompt input area and the context information input in the context introduction area.

[0047] In this embodiment, in addition to obtaining the code file under test in the current software project, it is also necessary to obtain multiple target project dependency information required to generate unit test code. Among them, the multiple target project dependency information includes at least the identifier of the target simulation framework and the identifier of the target test framework.

[0048] In practical applications, a current software project may depend on a software runtime environment, various versions of programming languages, multiple mocking frameworks, or multiple testing frameworks, etc. The target mocking framework can be any of the multiple mocking frameworks, and the target testing framework can be any of the multiple testing frameworks. In practical applications, there are no restrictions on the methods used to obtain the multiple target project dependency information required to generate unit test code.

[0049] Optionally, to support users in flexibly selecting project dependency information, the implementation method for obtaining multiple target project dependency information required to generate unit test code is as follows: obtain a list of project dependency information for the current software project and display the list on the project dependency information confirmation interface. The project dependency information list includes multiple project dependency information options, each of which is used to select one type of project dependency information; in response to the user's selection operation triggered for the project dependency information option, select one project dependency information from the multiple optional project dependency information corresponding to the project dependency information option; in response to the user's confirmation operation for the selected multiple project dependency information triggered on the project dependency information confirmation interface, use the selected multiple project dependency information as multiple target project dependency information required to generate unit test code.

[0050] Taking Figure 4 as an example, the AI ​​dialogue interaction interface displays a project dependency information confirmation interface. This interface shows a list of project dependencies, including options for environment setup tools, programming language versions, mocking frameworks, and testing frameworks. The environment setup tool option displays that the current software project's configured environment setup tool is Maven. Maven is a powerful project management and build tool, primarily used for building Java projects, managing dependencies, and generating documentation. The programming language version option allows users to select the desired programming language version. Each option is associated with one or more programming language versions for the user to choose from; for example, the user selects Java 9.2.2. The mocking framework option allows users to select the desired mocking framework. Each option is associated with one or more mocking frameworks for the user to choose from; for example, the user selects the mocking framework Mockito 5.7.0. The testing framework option allows users to select the desired testing framework. Each option is associated with one or more testing frameworks for the user to choose from; for example, the user selects the testing framework JUnit 5. When the user clicks the confirmation button in Figure 4, the selected project dependencies are confirmed as the required project dependencies.

[0051] Step 202: The unit test agent calls the large language model to analyze the code file under test and the dependency information of multiple target projects, and obtains the analysis results. The analysis results include the set of functions under test and the execution plan, as well as the unit test code corresponding to each test function under different test scenarios generated according to the execution plan based on the target simulation framework and the target test framework. The set of functions under test includes multiple functions under test extracted from the code file under test. The execution plan is used to instruct the sequential generation of the unit test code corresponding to each function under test based on the target simulation framework and the target test framework.

[0052] In practical applications, the unit testing agent inputs the code file under test and dependency information of multiple target projects into a large language model. The large language model performs intent understanding and requirement analysis, extracts multiple test functions from the code file under test, which can be any function in the code file under test, and the multiple test functions form a set of test functions. The large language model can also plan an execution plan, which can instruct the generation of unit test code corresponding to each test function in sequence based on the target simulation framework and the target testing framework, but is not limited to this.

[0053] Further optionally, to improve the quality of unit test code generation by the large language model, if the unit test code generation requirement information also includes: the identifier of the context information of the code file under test; then, based on the identifier of the context information of the code file under test, the context information of the code file under test is retrieved in the current software project; correspondingly, the implementation method of calling the large language model through the unit test agent to analyze the code file under test and the dependency information of multiple target projects to obtain the analysis results is as follows: the large language model is called through the unit test agent to analyze the code file under test, the context information, and the dependency information of multiple target projects to obtain the analysis results.

[0054] In practical applications, large language models can directly generate corresponding unit test code for the functions under test in the set of functions under test. Optionally, to better meet user needs and improve the flexibility of unit test code generation, it also supports users managing the set of functions under test on demand. In practice, a confirmation interface for the functions under test can also be displayed to users to allow them to manage the set of functions under test as needed.

[0055] Based on the above, before generating the unit test code corresponding to each test function in different test scenarios according to the execution plan based on the target simulation framework and the target test framework, the above method may further include: displaying a confirmation interface for the function under test, which includes multiple test code file options, each test code file option being associated with multiple test functions in the corresponding test code file; responding to the user's operation on any test code file option, displaying multiple test functions in the test code file corresponding to the test code file option; and responding to the user's confirmation operation on the test function confirmation interface, executing the step of generating the unit test code corresponding to each test function in different test scenarios according to the execution plan based on the target simulation framework and the target test framework. In practical applications, before responding to the user's confirmation operation on the test function confirmation interface, one or more test functions from the multiple test functions included in the test code file can also be deleted from the test function set in response to a user-triggered deletion operation. Optionally, to allow users to intuitively know how many test code files and how many test functions there are, summary data of the test code files and summary data of the test functions can be displayed on the test function confirmation interface.

[0056] Taking Figure 5 as an example, the AI ​​dialogue interaction interface displays a confirmation interface for the tested functions. This interface shows three code files under test, containing a total of 20 tested functions. The interface displays options for multiple code files under test, such as OrderServicelmpl.java, OrderService.java, and FileUtil.java. When the user clicks the OrderService.java option, it displays multiple tested functions within that file, namely insertOrder(), updateOrder(), deleteOrder(), makePayment(), and getRelatedOrders(). These tested functions implement different functionalities. In practical applications, operation controls can be provided within the code file options to expand and collapse the cards containing the multiple tested functions within those files. For example, in Figure 5, when the "Code File Under Test" option displays the > control, clicking the > control expands the card containing multiple functions under test within the code file. After expanding the card containing multiple functions under test, the > control changes to the ∧ control. Clicking the ∧ control again collapses the card, thus exiting the display of multiple functions under test within the code file. In practical applications, users can delete functions under test as needed. As shown in Figure 5, after a function is deleted, a deletion instruction message is displayed. After the user has selected all the functions under test, they can click the confirmation control in the function confirmation interface to confirm the set of functions under test.

[0057] In this embodiment, the large language model is invoked to generate unit test code for each test function under different test scenarios based on the target simulation framework and the target test framework according to the execution plan. The test scenarios can be flexibly defined as needed. In practical applications, the large language model can generate unit test code covering a wide variety of test scenarios, thereby improving test coverage.

[0058] Step 203: The unit test agent calls the compiler to compile the unit test code corresponding to each test function in different test scenarios, and calls the build tool to run the compiled unit test code to obtain the unit test code that each test function runs successfully in different test scenarios.

[0059] In practical applications, after the large language model generates unit test code for each test function under different test scenarios, the unit test agent can call the compiler to automatically compile the unit test code for each test function under different test scenarios. The unit test agent can also call the build tool to automatically run the compiled unit test code, resulting in successfully executed unit test code for each test function under different test scenarios. In essence, unit test code is code used to perform unit tests on the corresponding function under test.

[0060] In practical applications, unit test code may fail to compile or run. Unit test code that compiles successfully but fails to run can be addressed by having a unit test agent call the large language model to optimize the code based on relevant error messages. The unit test agent then compiles and runs the optimized code until successfully running unit test code is obtained. Essentially, the unit test agent compiles and runs the optimized code, calls the compiler to automate the compilation, and calls the build tools to automate the execution of the compiled and optimized code. This provides a solution for automatically compiling, running, and repairing (i.e., optimizing) unit test code, improving the success rate of automatically generating successfully running unit test code. Relevant error messages help the large language model pinpoint the reasons for compilation or runtime failures, thus better guiding the model in code repair.

[0061] In practical applications, multiple rounds of compilation, execution, and repair can be performed to improve the success rate of automatically generating and running unit test code, enhance the accuracy and usability of unit test code, significantly reduce the time developers spend in unit testing scenarios, and improve development efficiency.

[0062] The technical solution provided in this disclosure uses a unit test agent to call a large language model to generate unit test code for multiple test functions in multiple different test scenarios. The unit test agent then calls a compiler to automatically compile the unit test code generated by the large language model, and finally calls a build tool to automatically run the compiled unit test code. This achieves automatic generation, compilation, and execution of unit test code, enabling batch generation of unit test code covering various diverse test scenarios. This improves test coverage, increases the success rate of obtaining successfully running unit test code, enhances the accuracy and usability of unit test code, significantly reduces the time and maintenance costs for developers in unit testing scenarios, and improves the development efficiency and code quality of unit test code.

[0063] Understandably, the system allows users to select multiple code files and modify code content to generate unit test code in batches, significantly improving the efficiency of unit test code generation when multiple functions have changed. It also allows users to intervene in project dependency information and the selection of functions under test, ensuring that the large language model accurately understands user requirements.

[0064] In some optional embodiments, users are also allowed to view the unit test code generation progress interface, which allows them to understand the generation status of unit test code in real time, enhancing the transparency of the development process and improving development efficiency and user experience.

[0065] Based on the above, the method further includes: displaying a unit test code generation progress interface, which includes the following information: first progress information, indicating the number of tested functions in multiple tested code files for which unit test code has been generated; second progress information, indicating the status summary information of all unit test codes in multiple tested code files, with different statuses corresponding to different style icons, and the number of unit test codes in the corresponding status displayed around each icon to indicate the status summary information of the unit test codes in the corresponding status, the status summary information of unit test codes in different statuses including at least two of the following: the number of unit test codes that ran successfully, the number of unit test codes that failed to run, or the number of unit test codes that failed to compile; and third progress information for each tested code file, indicating the number of tested functions in at least one tested function corresponding to the tested code file for which unit test code has been generated.

[0066] Optionally, to meet more diverse user needs, the unit test code generation progress interface also includes: card operation controls for each code file under test; when the card corresponding to the code file under test is in a collapsed state, the card operation controls are used to trigger the display of the card corresponding to the code file under test; when the card corresponding to the code file under test is in an expanded state, the card operation controls are used to trigger the collapse of the card corresponding to the code file under test.

[0067] The card corresponding to the code file under test displays the fourth progress information for each function under test within the code file under test. The fourth progress information for each function under test is used to indicate the status of the unit test code under the function under test. The status of the unit test code under the function under test includes at least two of the following: generating, running, fixing, or generated. If the status of the unit test code under the function under test is generated, the status summary information of the unit test code under the function under test in different states is displayed.

[0068] For example, as shown in Figure 6, the unit test code generation progress interface is displayed on the AI ​​dialogue interaction interface. The first progress information "10 / 20 functions under test have been completed" means that the unit test code has been generated for 10 out of the 20 functions under test. The icon represents the unit test code that ran successfully. The icon represents unit test code that failed to run. The icon represents the unit test code that failed to compile; by overlaying the icon and the number, the number of unit test codes that ran successfully (15), the number of unit test codes that failed to run (3), or the number of unit test codes that failed to compile (1) can be displayed.

[0069] Referring to Figure 6, all nine tested functions in the OrderServicelmpl.java test file have completed the execution or compilation of their corresponding unit test code; only one of the five tested functions in the OrderService.java test file has completed the execution or compilation of its corresponding unit test code; and none of the six tested functions in the FileUtil.java test file have completed the execution or compilation of their corresponding unit test code.

[0070] Referring to Figure 6, the card operation controls corresponding to each tested code file are shown. When the > card operation control in OrderService.java is clicked, cards containing the five tested functions of OrderService.java are displayed, and the > card operation control transforms into a ∨ card operation control. When the user clicks the ∨ card operation control, the cards in OrderService.java are collapsed, and the ∨ card operation control transforms back into the > card operation control. In other words, the cards corresponding to the > card operation control are in a collapsed state, while the cards corresponding to the ∨ card operation control are in an expanded state.

[0071] Referring to Figure 6, after expanding the cards containing the five tested functions of OrderService.java, the status of the tested functions is as follows: insertOrder() is "Completed," updateOrder() is "Compiling," deleteOrder() is "Running," and makePayment() is "Repairing" or getRelatedOrders() is "Building." The "Completed" status of insertOrder() indicates that all unit test code for this function has been executed or compiled. Specifically, 4 unit test codes for insertOrder() ran successfully, 1 failed, and 0 failed to compile. The unit test code for updateOrder() has not yet been compiled and is currently in the "Compiling" state; the unit test code for deleteOrder() has not yet been executed and is currently in the "Running" state; the unit test code for makePayment() has been executed or compiled but is currently in the "Repairing" state; and getRelatedOrders() has not yet generated all unit test code and is currently in the "Building" state.

[0072] In some optional embodiments, users are also allowed to view the unit test code viewing interface, which allows them to understand the details of the unit test code in real time, enhancing the transparency of the development process and improving development efficiency and user experience.

[0073] Based on the above, the method further includes: displaying a unit test code viewing interface, which includes a list of test code files, each containing file identifiers for multiple test code files; expanding the test code file cards in response to a user's action to expand the cards; wherein the test code file cards display a first entry control and a first statistical result for a first unit test code list, the first unit test code list including successfully executed or failed unit test codes, the first statistical result indicating the number of unit test codes in the first unit test code list, and the unit test codes in the first unit test code list having been added to the test code files; displaying the first unit test code list in response to a user's action to trigger the first entry control, the first unit test code list including multiple unit test codes and their corresponding scenario description information; and adding the test code files containing the added unit test codes to the current software project in response to a user's acceptance action in the unit test code viewing interface. The scenario description information of the unit test codes describes relevant information about the test scenarios of the unit test codes.

[0074] Further optionally, in order to meet the diverse needs of users and improve the reliability and accuracy of unit test code generation, before responding to the user's accept operation triggered in the unit test code viewing interface, the above method further includes: in response to the user's deselection operation of unit test code in the first unit test code list, deleting the selected unit test code from the test code file; or, in response to the user's manual repair operation of unit test code that failed to run in the first unit test code list, repairing the unit test code that failed to run.

[0075] Optionally, to meet diverse user needs and improve the reliability and accuracy of unit test code generation, the test code file card displays a second entry control for a second unit test code list and a second statistical result. The second unit test code list includes unit test codes that failed to compile, and the second statistical result indicates the number of unit test codes in the second unit test code list. The unit test codes in the second unit test code list have not yet been added to the test code file. In response to the user triggering the second entry control, the second unit test code list is displayed, which includes multiple unit test codes and their corresponding scenario descriptions. In response to the user's manual repair operation on the unit test codes that failed to compile in the second unit test code list, the unit test codes that failed to compile are repaired. And in response to the operation of adding the repaired unit test codes that failed to compile to the test code file, the repaired unit test codes are added to the test code file.

[0076] Optionally, to meet diverse user needs, the unit test code viewing interface also displays the number of test code files and the total number of unit test codes from all tested code files.

[0077] Specifically, a new test code file is created for each code file under test. This test code file stores the unit test code selected from the unit test code of the corresponding function in the code file under test. In practice, successfully executed or unexecuted unit test code can be automatically added to the test code file. Unexecuted unit test code refers to unit test code that compiles successfully but fails to run. Whether or not to add unexecuted unit test code to the test code file can be decided manually.

[0078] For example, referring to Figure 7, the unit test code viewing interface displays "Involves 3 test code files, with a total of 50 unit test codes." That is, the 3 test code files are: OrderServicelmplTest.java (corresponding to the test file OrderServicelmpl.java), OrderServiceTest.java (corresponding to the test file OrderService.java), and FileUtil Test.java (corresponding to the test file FileUtil.java). These 3 test files generate 50 unit test codes. Of these 50 unit test codes, 32 have been applied to their respective test code files; 18 require confirmation, meaning manual confirmation is needed to add them to their corresponding test code files. Referring to Figure 7, test code files in the fully selected state include all unit test codes corresponding to the test files; test code files in the partially selected state include some unit test codes corresponding to the test files; and test code files in the unselected state have not yet had unit test codes added.

[0079] Referring to Figure 7, the file identifier of the OrderServiceTest.java test code file is surrounded by a card operation control (not shown). The card for the OrderServiceTest.java test code file is initially collapsed. When the corresponding card operation control for OrderServiceTest.java is clicked, the card containing the card is displayed, and the card transforms into a ∨ card operation control. The card displays the first entry control and the first statistical result "20 unit test codes have been applied" for the first unit test code list, and the second entry control and the second statistical result "5 unit test codes need confirmation" for the second unit test code list. The > control around the text "20 unit test codes have been applied" is the first entry control; the > control around the text "5 unit test codes need confirmation" is the second entry control. The first unit test code list corresponding to "20 unit test codes have been applied" is fully selected, indicating that 20 unit test codes have been applied to the corresponding test code file; the second unit test code list corresponding to "5 unit test codes need confirmation" is unselected, indicating that 5 unit test codes require manual confirmation and have not yet been added to the corresponding test code file.

[0080] When a user triggers the display of the first or second list of unit test code, for the selected unit test code, the user can trigger a deselection operation to change the selected unit test code to an unselected unit test code; conversely, for the unselected unit test code, the user can trigger a selection operation to change the unselected unit test code to a selected unit test code.

[0081] Figure 7 shows the scenario description information for the selected `insertOrderTest()` unit test code and its successful execution status. It also shows the scenario description information for the selected `updateOrderTest()` unit test code and its failed execution status; the scenario description information for the unselected `deleteOrderTest()` unit test code and its compilation failure status; the scenario description information for the unselected `makePaymentTest()` unit test code and its compilation failure status; and the scenario description information for the unselected `getRelatedOrdersTest()` unit test code and its compilation failure status.

[0082] In practical applications, users can view the code content of any unit test and manually fix its contents. For example, they can manually fix unit test code that has failed to compile or run.

[0083] In practical applications, as shown in Figure 7, after the user confirms the selected unit test code, they can click the accept control on the unit test code viewing interface to confirm the selected unit test code and add the test code file containing the selected unit test code to the current software project, thus meeting the user's code review requirements and adopting the required unit test code as needed.

[0084] Referring to Figure 8, users can also view the code changes in any test file. For test files with code changes, code difference comparison technology is used to compare the code changes and display them on the relevant interactive interface, so that users can easily view, revise, and make adoption decisions regarding the code changes.

[0085] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 201 to 203 can be device A; or the execution subject of steps 201 and 202 can be device A, and the execution subject of step 203 can be device B; and so on.

[0086] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 401, 402, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0087] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0088] Figure 9 is a schematic diagram of an electronic device provided in an exemplary embodiment of the present disclosure. As shown in Figure 9, the electronic device includes: a memory 91 and a processor 92;

[0089] Memory 91 is configured to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc.

[0090] The memory 91 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0091] Processor 92, coupled to memory 91, is configured to execute a computer program in memory 91 for: obtaining the code file under test in the current software project and obtaining multiple target project dependency information required to generate unit test code, wherein the multiple target project dependency information includes at least the identifier of the target simulation framework and the identifier of the target test framework; analyzing the code file under test and the multiple target project dependency information by calling a large language model through a unit test agent, obtaining analysis results, including a set of functions under test and an execution plan, and generating unit test code corresponding to each test function under different test scenarios according to the execution plan based on the target simulation framework and the target test framework; wherein the set of functions under test includes multiple functions under test extracted from the code file under test; the execution plan is used to instruct the sequential generation of unit test code corresponding to each function under test based on the target simulation framework and the target test framework; compiling the unit test code corresponding to each test function under different test scenarios by calling a compiler through a unit test agent, and calling a build tool to run the compiled unit test code, obtaining the successfully run unit test code of each test function under different test scenarios.

[0092] Optionally, processor 92 is also configured to: if there are unit test codes that fail to compile or fail to run, then use the unit test agent to call the large language model to repair the unit test codes that fail to compile or fail to run by combining the relevant error information of the unit test codes that fail to compile or fail to run; use the unit test agent to compile and run the repaired unit test codes until successfully running unit test codes are obtained.

[0093] Optionally, when processor 92 obtains the code file under test in the current software project, it is configured to: receive unit test code generation requirement information input by the user for the current software project, the unit test code generation requirement information being used to indicate the identifier of the code file under test or to indicate the generation of corresponding unit test code for code changes; if the unit test code generation requirement information indicates the identifier of the code file under test, then the code file under test is retrieved in the current software project; if the unit test code generation requirement information indicates the generation of corresponding unit test code for code changes, then the code changes are retrieved in the current software project, and the modified code file involved in the code changes is taken as the code file under test.

[0094] Optionally, the unit test code generation requirement information also includes: an identifier of the context information of the code file under test; the processor 92 is also configured to: retrieve the context information of the code file under test in the current software project based on the identifier of the context information of the code file under test; correspondingly, when the processor 92 calls the large language model through the unit test agent to analyze the code file under test and the dependency information of multiple target projects and obtain the analysis results, it is specifically configured to: call the large language model through the unit test agent to analyze the code file under test, the context information and the dependency information of multiple target projects and obtain the analysis results.

[0095] Optionally, the number of code files to be tested can be multiple.

[0096] Optionally, when processor 92 obtains multiple target project dependency information required to generate unit test code, it is specifically configured to: obtain a list of project dependency information for the current software project and display the list on a project dependency information confirmation interface, the list including multiple project dependency information options, each project dependency information option being used to select one type of project dependency information; in response to a selection operation triggered by the user for a project dependency information option, select one project dependency information from the multiple optional project dependency information corresponding to the project dependency information option; in response to a confirmation operation triggered by the user on the project dependency information confirmation interface for the selected multiple project dependency information, use the selected multiple project dependency information as multiple target project dependency information required to generate unit test code.

[0097] Optionally, before generating the unit test code corresponding to each test function in different test scenarios based on the target simulation framework and target test framework according to the execution plan, the processor 92 is further configured to: display a confirmation interface for the function under test, which includes multiple test code file options, each test code file option being associated with multiple test functions in the corresponding test code file; in response to the user's operation on any test code file option, display multiple test functions in the test code file corresponding to the test code file option; in response to a deletion operation triggered by the user, delete one or more test functions from the set of test functions included in the test code file; and in response to the user's confirmation operation on the confirmation interface for the function under test, execute the steps of generating the unit test code corresponding to each test function in different test scenarios according to the execution plan based on the target simulation framework and target test framework.

[0098] Optionally, the processor 92 is further configured to: display a unit test code generation progress interface, which includes the following information: first progress information, indicating the number of tested functions in multiple tested code files for which unit test code has been generated; second progress information, indicating the status summary information of all unit test codes in multiple tested code files, with different styles of icons corresponding to different statuses of unit test codes, and the number of unit test codes in the corresponding status displayed around each icon to indicate the status summary information of the unit test codes in the corresponding status, the status summary information of unit test codes in different statuses including at least two of the following: the number of unit test codes that ran successfully, the number of unit test codes that failed to run, or the number of unit test codes that failed to compile; and third progress information for each tested code file, indicating the number of tested functions in at least one tested function corresponding to the tested code file for which unit test code has been generated.

[0099] Optionally, the unit test code generation progress interface also includes: card operation controls corresponding to each code file under test; when the card corresponding to the code file under test is in a collapsed state, the card operation controls are used to trigger the display of the card corresponding to the code file under test; when the card corresponding to the code file under test is in an expanded state, the card operation controls are used to trigger the collapse of the card corresponding to the code file under test; the card corresponding to the code file under test displays the fourth progress information corresponding to each function under test in the code file under test, and the fourth progress information corresponding to the function under test is used to indicate the status of the unit test code under the function under test; the status of the unit test code under the function under test includes at least two of the following: generating, running, fixing, or generated; wherein, if the status of the unit test code under the function under test is generated, the status summary information of the unit test code under the function under test in different states is displayed.

[0100] Optionally, the processor 92 is further configured to: display a unit test code viewing interface, which includes a list of test code files, each containing file identifiers for multiple test code files; expand the test code file cards in response to a user's action to expand the cards; wherein the test code file cards display a first entry control and a first statistical result for a first unit test code list, the first unit test code list including successfully executed or failed unit test codes, the first statistical result indicating the number of unit test codes in the first unit test code list, and the unit test codes in the first unit test code list having been added to the test code files; display the first unit test code list in response to a user's action to trigger the first entry control, the first unit test code list including multiple unit test codes and their corresponding scenario description information; and add the test code files containing the added unit test codes to the current software project in response to a user's acceptance action in the unit test code viewing interface.

[0101] Optionally, prior to the user's accept operation triggered in the unit test code viewing interface, the processor 92 is further configured to: delete the selected unit test code from the test code file in response to the user's deselection operation of the unit test code in the first unit test code list; or, repair the unit test code that failed to run in response to the user's manual repair operation of the unit test code that failed to run in the first unit test code list.

[0102] Optionally, the test code file card displays a second entry control and a second statistical result for the second unit test code list. The second unit test code list includes unit test codes that failed to compile, and the second statistical result indicates the number of unit test codes in the second unit test code list. The unit test codes in the second unit test code list have not yet been added to the test code file.

[0103] The processor 92 is also configured to: in response to a user triggering the second entry control, display a second unit test code list, which includes multiple unit test codes and their corresponding scenario description information; in response to a user's manual repair operation on the unit test codes that failed to compile in the second unit test code list, repair the unit test codes that failed to compile; and in response to an operation to add the repaired unit test codes that failed to compile to the test code file, add the repaired unit test codes that failed to compile to the test code file.

[0104] Optionally, the unit test code viewing interface also displays the number of test code files and the total number of unit test codes from all tested code files.

[0105] Optionally, as shown in Figure 9, the electronic device may also include other components such as a communication component 93, a display 94, a power supply component 95, and an audio component 96. Figure 9 only schematically shows some components and does not imply that the electronic device only includes the components shown in Figure 9. Furthermore, the components within the dashed boxes in Figure 9 are optional, not mandatory, and their specific inclusion depends on the product form of the electronic device. The electronic device of this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device of this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed boxes in Figure 9; if the electronic device of this embodiment is a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed boxes in Figure 9.

[0106] For a detailed description of the implementation process of each action by the processor, please refer to the relevant descriptions in the foregoing method embodiments or device embodiments, which will not be repeated here.

[0107] Accordingly, this disclosure also provides a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by an electronic device in the above method embodiments.

[0108] Accordingly, this disclosure also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to perform the steps that can be executed by an electronic device in the above method embodiments.

[0109] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi (Wireless Fidelity), 2G (2nd Generation), 3G (3rd Generation), 4G (4th Generation) / LTE (long Term Evolution), 5G (5th Generation), or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth, and other technologies. The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from a user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. The aforementioned power supply component provides power to various components of the device in which the power supply component resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides. The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device in which the audio component resides is in an operating mode, such as a call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker configured to output audio signals.

[0110] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0113] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0114] In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory.

[0115] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0116] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be configured to store information accessible by a computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

[0117] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0118] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A method for generating unit test code based on a large language model, comprising: Obtain the code file under test in the current software project and obtain multiple target project dependency information required to generate unit test code, wherein the multiple target project dependency information includes at least the identifier of the target simulation framework and the identifier of the target test framework; The unit testing agent invokes a large language model to analyze the code file under test and the dependency information of the multiple target projects, obtaining analysis results. These results include a set of functions under test and an execution plan, as well as unit test code generated for each function in different test scenarios based on the target simulation framework and the target testing framework, according to the execution plan. The set of functions under test includes multiple functions extracted from the code file under test. The execution plan instructs the sequential generation of unit test code for each function under test based on the target simulation framework and the target testing framework. The unit test agent calls the compiler to compile the unit test code for each test function under different test scenarios, and calls the build tool to run the compiled unit test code, thus obtaining the unit test code for each test function that runs successfully under different test scenarios.

2. The method according to claim 1, wherein, Also includes: If there are unit test codes that fail to compile or run, the unit test agent calls the large language model to optimize the unit test codes by combining the relevant error information of the unit test codes that fail to compile or run. The optimized unit test code is compiled and run by the unit test agent until the successfully running unit test code is obtained.

3. The method according to claim 1, wherein, Obtaining the code files under test in the current software project includes: The system receives unit test code generation requirement information for the current software project input by the user. The unit test code generation requirement information is used to indicate the identifier of the code file under test or to indicate the generation of corresponding unit test code for code changes. If the unit test code generation requirement information indicates the identifier of the code file under test, then the code file under test is retrieved in the current software project; If the unit test code generation requirement information indicates that the corresponding unit test code is generated for the code change content, then the code change content is retrieved in the current software project, and the changed code file involved in the code change content is taken as the code file under test.

4. The method according to claim 1, wherein, The unit test code generation requirement information also includes: an identifier of the context information of the code file under test; the method further includes: retrieving the context information of the code file under test in the current software project based on the identifier of the context information of the code file under test. Accordingly, the unit test agent invokes a large language model to analyze the tested code file and the dependency information of the multiple target projects, obtaining the analysis results, including: The unit test agent invokes a large language model to analyze the tested code file, the context information, and the dependency information of the multiple target projects, and obtains the analysis results.

5. The method according to claim 1, wherein, The number of code files being tested is multiple.

6. The method according to claim 1, wherein, Obtain the dependency information of multiple target projects required to generate unit test code, including: Obtain the project dependency information list of the current software project and display the project dependency information list on the project dependency information confirmation interface. The project dependency information list includes multiple project dependency information options, and each project dependency information option is used to select a type of project dependency information. In response to a user's selection operation triggered by the project dependency information option, select one project dependency information from multiple optional project dependency information corresponding to the project dependency information option; In response to the user's confirmation operation on the project dependency information confirmation interface for the selected multiple project dependency information, the selected multiple project dependency information is used as multiple target project dependency information required to generate unit test code.

7. The method according to claim 1, wherein, Before generating the unit test code for each test function under different test scenarios according to the execution plan based on the target simulation framework and the target test framework, the process also includes: The interface for confirming the function under test is displayed. The interface for confirming the function under test includes multiple code file options under test. Each code file option under test is associated with multiple functions under test in the corresponding code file under test. In response to the user's operation on any test code file option, multiple test functions in the test code file corresponding to the test code file option are displayed; In response to the deletion operation triggered by the user, one or more of the multiple functions under test included in the code file under test are deleted from the set of functions under test; In response to the user's confirmation operation on the confirmation interface of the function under test, the step of generating unit test code for each test function under different test scenarios according to the execution plan based on the target simulation framework and the target test framework is executed.

8. The method according to claim 1, wherein, Also includes: The unit test code generation progress interface is displayed, and the unit test code generation progress interface includes the following information: First progress information, which is used to indicate the number of tested functions in all tested functions under multiple tested code files that have generated unit test code; The second progress information is used to indicate the status summary information of all unit test codes under multiple test code files. Different statuses of unit test codes correspond to different styles of icons. The number of unit test codes in the corresponding status is displayed around each icon to indicate the status summary information of the unit test codes in the corresponding status. The status summary information of unit test codes in different statuses includes at least two of the following: the number of unit test codes that run successfully, the number of unit test codes that fail to run, or the number of unit test codes that fail to compile. The third progress information for each code file under test indicates the number of tested functions for which unit test code has been generated in at least one tested function corresponding to the code file under test.

9. The method according to claim 7, wherein, The unit test code generation progress interface also includes: a card operation control corresponding to each code file under test; when the card corresponding to the code file under test is in a collapsed state, the card operation control is used to trigger the display of the card corresponding to the code file under test; when the card corresponding to the code file under test is in an expanded state, the card operation control is used to trigger the collapse of the card corresponding to the code file under test. The card corresponding to the code file under test displays the fourth progress information for each function under test in the code file under test. The fourth progress information for each function under test is used to indicate the status of the unit test code under the function under test. The status of the unit test code under the function under test includes at least two of the following: generating, running, repairing, or generated. If the status of the unit test code under the function under test is generated, then the status summary information of the unit test code under the function under test in different states is displayed.

10. The method according to claim 1, wherein, Also includes: The unit test code viewing interface is displayed. The unit test code viewing interface includes a list of test code files, and the list of test code files includes file identifiers of multiple test code files. In response to a user triggering an operation to expand the card of the test code file, the card of the test code file is expanded; wherein, the card of the test code file displays a first entry control for a first unit test code list and a first statistical result, the first unit test code list includes unit test code that runs successfully or unit test code that fails to run, the first statistical result indicates the number of unit test codes in the first unit test code list, and the unit test codes in the first unit test code list have been added to the test code file; In response to the user's operation of triggering the first entry control, the first unit test code list is displayed, which includes multiple unit test codes and their corresponding scenario description information; In response to the user's acceptance action triggered in the unit test code viewing interface, the test code file containing the unit test code is added to the current software project.

11. The method according to claim 10, wherein, Prior to the accept operation triggered by the user in the unit test code viewing interface, the method further includes: In response to the user's deselection operation of unit test codes in the first unit test code list, the selected unit test codes are deleted from the test code file; or, In response to the user's manual repair operation on the unit test code that failed to run in the first unit test code list, the unit test code that failed to run is repaired.

12. The method according to claim 10, wherein, The test code file displays a card with a second entry control and a second statistical result for a second unit test code list. The second unit test code list includes unit test codes that failed to compile. The second statistical result indicates the number of unit test codes in the second unit test code list. The unit test codes in the second unit test code list have not yet been added to the test code file. In response to the user's operation of triggering the second entry control, the second unit test code list is displayed, which includes multiple unit test codes and their corresponding scenario description information; In response to the user's manual repair operation on the unit test code that failed to compile in the second unit test code list, the unit test code that failed to compile is repaired; In response to the operation of adding the fixed compilation failure unit test code to the test code file, the fixed compilation failure unit test code is added to the test code file.

13. The method according to claim 10, wherein, The unit test code viewing interface also displays the number of test code files and the total number of unit test codes from all the tested code files.

14. The method according to claim 3, wherein, The code changes mentioned involve modifying the following code files: adding code, deleting code, and altering code in the source code files.

15. The method according to claim 4, wherein, The identifier of the context information of the code file under test is received through the context introduction area; the context introduction area supports selecting the file identifiers of one or more files at a time, and using the file identifiers as the identifiers of the context information.

16. The method according to claim 7, wherein, The interface for confirming the function under test also displays summary data of the code file under test and summary data of the function under test; furthermore, the code file under test option provides operation controls for expanding or collapsing the cards that contain the multiple functions under test in the code file under test.

17. The method according to claim 10, wherein, Also includes: The code changes in the test code file are compared, and the code changes are displayed in the unit test code viewing interface.

18. An electronic device comprising: Memory and processor; The memory is configured to store computer programs; The processor is coupled to the memory and configured to execute the computer program to perform the steps of the method according to any one of claims 1 to 13.

19. A computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1 to 13.

20. A computer program product comprising a computer program or instructions that, when executed by a processor, cause the processor to perform the steps of the method according to any one of claims 1 to 13.

Images