Front-end integrated unit testing method, device, equipment, medium and program product

Abstract

The invention provides a front-end integrated unit testing method, device and equipment, a medium and a program product, which can be applied to the technical field of unit testing. The method comprises the steps that a code file of a first front-end project is obtained based on a version control system, the first front-end project is not integrated with a unit test framework, and the code file at least comprises an incremental code file newly added and / or modified in the version issuing process; extracting a target function which needs to be subjected to unit testing from the code file through a regular matching rule adaptive to a first front-end project technology architecture function definition grammar; generating a basic test case template based on the structure information of the target function, and converting the basic test case template into an executable test code according to a grammar specification of a preset bottom layer unit test framework; establishing a unit test core system comprising a bottom layer unit test tool, version difference analysis logic, a regular matching screening rule and a test case writing grammar specification; and testing the target function by using the unit test system.

Description

Technical Field

[0001] This application relates to the field of unit testing technology, and in particular to a front-end integration unit testing method, apparatus, device, medium, and program product. Background Technology

[0002] In a browser / server architecture, for front-end projects that do not yet integrate unit tests, it is difficult to quickly build a complete and universal unit test framework for different project architectures. Even if a new test framework is created, there will be the problem that existing code is not covered by unit test cases. Covering the existing code will result in a large workload, which is not conducive to agile development of the project and will lead to a lack of guarantee of code correctness.

[0003] Currently, the front-end uses a unit testing framework to generate unit test reports. This framework needs to be imported as needed for different technical architectures. It scans the units in the project that require unit test coverage, then writes test cases for the corresponding units through relevant configurations, and finally scans the project through a cross-platform script runtime environment to generate a unit test coverage report. Existing testing methods cannot meet the needs of this application. Summary of the Invention

[0004] In view of the above problems, this application provides front-end integration unit testing methods, apparatus, devices, media, and program products.

[0005] According to the first aspect of this application, a front-end integrated unit testing method is provided, comprising: obtaining code files of a first front-end project based on a version control system, wherein the first front-end project does not integrate a unit testing framework, and the code files at least contain incremental code files added and / or modified in the current release; extracting target functions to be unit tested from the code files by using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project's technical architecture, and parsing to obtain the structural information of the target functions; generating a basic test case template containing input parameter boundary value examples, normal return examples, and abnormal scenario placeholders based on the structural information of the target functions, and converting the basic test case template into executable test code according to the syntax specifications of a preset underlying unit testing framework; building a unit testing system including underlying unit testing tools, version difference analysis logic based on the version control system, the regular expression matching rules, and test case writing syntax specifications, wherein the basic test case template is generated based on the test case writing syntax specifications combined with the structural information of the target functions; and testing the target functions using the unit testing system.

[0006] According to an embodiment of this application, obtaining the code file of the first front-end project based on the version control system includes: executing the version control system's difference comparison command through the difference comparison process module of the scripting language runtime environment to obtain code difference information between the current release and the previous version; filtering out the incremental code added and / or modified in this release based on the code difference information; and constructing a code file based on the file containing the incremental code.

[0007] According to an embodiment of this application, the method further includes: detecting the target method in the target object that needs to be unit tested in the current version of the code; if the target method is a newly added method that is not recorded in the local file system, then adding a corresponding unit test case record, wherein the local file system records the historical method information that has been unit tested in the first front-end project.

[0008] According to an embodiment of this application, the method further includes: obtaining a portion of the code files of a second front-end project based on a version control system. The second front-end project does not integrate a unit testing framework. The first and second front-end projects have the same underlying core unit testing tools, version control system difference analysis logic, regular expression matching filtering rules, and test case writing syntax specifications, but have different front-end technology architectures or architecture-specific syntaxes. The method further includes: filtering out target objects that need to be unit tested from a portion of the code files of the second front-end project using regular expression matching technology; and testing the target objects of the second front-end project using a unit testing system.

[0009] According to an embodiment of this application, the target objects to be unit tested are selected from the code file using regular expression matching technology, including: extracting the target functions from the target objects to be unit tested from the code file based on regular expression matching technology; storing the target functions in a local file and using them to generate corresponding unit test cases.

[0010] According to an embodiment of this application, generating corresponding unit test cases includes: inputting prompt words into a large model, the prompt words instructing the large model to perform the following operations: based on a basic test case template, and combined with the business logic of the target function, filling in at least one of the assertion rules for actual input parameters, expected return results, or abnormal scenarios; converting the filled basic test case template into executable test code compatible with the syntax of a preset underlying unit test framework; performing syntax verification and logic compatibility verification on the executable test code, correcting content that does not conform to the specifications of the underlying unit test framework or conflicts with the logic of the target function, and obtaining unit test cases.

[0011] The second aspect of this application provides a front-end integrated unit testing device, comprising: an incremental code acquisition module, used to acquire code files of a first front-end project based on a version control system, wherein the first front-end project does not integrate a unit testing framework, and the code files at least contain incremental code files added and / or modified in the current release; a target object filtering module, used to extract target functions to be unit tested from the code files by using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project's technical architecture, and to parse and obtain the parameter types, default values, and return value structures of the target functions; and a test system building module, used to generate a basic test case template containing input parameter boundary value examples, normal return examples, and abnormal scenario placeholders based on the structural information of the target functions, and to convert the basic test case template into executable test code according to the syntax specifications of a preset underlying unit testing framework; to build a unit testing system including underlying unit testing tools, version difference analysis logic based on the version control system, the regular expression matching rules, and test case writing syntax specifications, wherein the basic test case template is generated based on the test case writing syntax specifications combined with the structural information of the target functions; and to test the target functions using the unit testing system.

[0012] A third aspect of this application provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0013] A fourth aspect of this application also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0014] The fifth aspect of this application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0015] Based on the front-end integrated unit testing method, apparatus, equipment, media, and program products provided in this application, incremental code files of the first front-end project are obtained through a version control system. Regular expression matching technology is used to filter target objects requiring unit testing, and a unit testing system adapted to the project is built and tested on the target objects. By using a unified system, the redundant construction of testing systems across different architectures is avoided, and there is no need to rely on pre-integrated unit testing frameworks. Therefore, this approach at least partially solves the problems of large workload, vague test objectives, and high difficulty in building testing systems for front-end projects without integrated unit testing frameworks, as well as the problems of redundant construction of testing systems across different architectures and low accuracy in extracting target functions. It achieves the technical effects of lightweight unit testing system construction for cross-architecture reuse, efficient and accurate unit testing, and reduced testing implementation costs for front-end projects without integrated testing frameworks. Attached Figure Description

[0016] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustration shows an application scenario diagram of the front-end integration unit testing method, apparatus, device, medium, and program product according to embodiments of this application;

[0018] Figure 2 A flowchart illustrating a front-end integration unit testing method according to an embodiment of this application is shown schematically.

[0019] Figure 3 This schematic diagram illustrates the principle of obtaining a portion of the code files of a first front-end project according to an embodiment of this application.

[0020] Figure 4 A flowchart illustrating another front-end integration unit testing method according to an embodiment of this application is shown schematically;

[0021] Figure 5 The schematic diagram illustrates the principle of generating corresponding unit test cases according to an embodiment of this application;

[0022] Figure 6 This schematically illustrates a structural block diagram of a front-end integration unit test apparatus according to an embodiment of this application; and

[0023] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a front-end integration unit testing method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0029] In the technical solution of this application, the collection, storage, use, processing, transmission, provision, application and application of user personal information all comply with the provisions of relevant laws and regulations, take necessary security measures, and do not violate public order and good morals.

[0030] In the technical solution of this application, the acquisition, collection, storage, use, processing, transmission, provision, application and application of data all comply with the provisions of relevant laws and regulations, take necessary security measures, and do not violate public order and good morals.

[0031] Front-end: The webpages that run on a personal computer or mobile browser and are displayed to the user using Hypertext Markup Language, Cascading Style Sheets, or scripting languages.

[0032] Unit testing refers to the inspection and verification of the smallest testable unit in software. A unit can be a function, method, class, functional module, or subsystem.

[0033] The proposed solutions introduce unit testing frameworks based on the technical architecture, but require customized configuration of the frameworks and a cross-platform script runtime environment to drive the frameworks to scan unit test coverage, which incurs certain technical costs.

[0034] After referencing a framework, corresponding unit test cases need to be written for the existing code. For large projects, the code that needs to be covered is often extensive, the configuration is complex, and the workload is large, making it impossible to scan for incremental code in the current version.

[0035] This application provides a front-end integrated unit testing method. For projects without an integrated unit testing framework, it offers a non-intrusive integrated unit testing approach, and, in conjunction with code management tools, allows for unit testing of incremental code. For projects without an integrated unit testing framework, or projects with excessive existing code leading to a heavy workload for writing unit tests, this method can quickly achieve unit test coverage for locally released incremental and modified code. In some embodiments, differences in integrated testing frameworks between different projects can be ignored, and iterative management of unit test cases for different versions is also implemented.

[0036] Figure 1 The illustration shows an application scenario diagram of the front-end integration unit testing method, apparatus, device, medium, and program product according to embodiments of this application.

[0037] like Figure 1 As shown, application scenario 100 according to this embodiment may include terminal devices 101, 102, and 103, network 104, and server 105. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0038] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0039] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0040] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0041] It should be noted that the front-end integration unit testing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the front-end integration unit testing device provided in this application embodiment can generally be located in server 105. The front-end integration unit testing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the front-end integration unit testing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0042] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0043] The following will be based on Figure 1 The described scene, through Figures 2-5 The front-end integration unit testing method of the application embodiment is described in detail.

[0044] Figure 2 A flowchart illustrating a front-end integration unit testing method according to an embodiment of this application is shown.

[0045] like Figure 2 As shown, the front-end integration unit testing method of this embodiment includes operations S210 to S250.

[0046] In operation S210, the code files of the first front-end project are obtained based on the version control system. The first front-end project does not integrate a unit testing framework, and the code files contain at least the incremental code files added and / or modified in this release.

[0047] This operation leverages existing version control tools to compare the differences between this release and previous versions (such as the previous version), filtering out newly added and / or modified incremental code files and excluding unchanged existing files, thus narrowing down the scope of subsequent processing. Since the first front-end project does not integrate a testing framework, this step does not rely on internal project configurations and can be completed independently using version control tools.

[0048] This operation can obtain partial code files of the first front-end project based on the version control system. For example, if a first front-end project has 10 files modified in this release, it can obtain these 10 files of the first front-end project based on the version control system, or it can obtain 5 or other numbers of these 10 files of the first front-end project based on the version control system.

[0049] For example, this operation can use the commit hash value (such as a1b2c3d) or branch (such as master) of the version control system corresponding to the previous release as a baseline, and execute the difference comparison command: call the relevant command through the script in the project root directory to obtain the list of file differences between the current release branch and the baseline version, and extract the target file.

[0050] This operation can also determine the baseline version and execute relevant commands to obtain all changed files; exclude configuration files, static resource files, automatically generated files, etc. through scripts, and only retain code files containing business logic; categorize the filtered files by additions and modifications, and extract the target files.

[0051] In operation S220, by using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project's technical architecture, the target function to be unit tested is extracted from the code file, and the structural information of the target function is obtained by parsing.

[0052] In this operation, regular expression matching rules are used to customize the function definition syntax of the first front-end project, and the target functions to be tested are selected from the incremental code files. The extracted target functions are then subjected to structured parsing to extract core information such as parameter types, default values, return value structure, parameter validation / exception logic, etc., to provide a basis for generating test templates in the future.

[0053] For example, it can read part of the code file content obtained by operation S210; use regular expressions to traverse the file content, extract function names, and remove duplicates; filter system built-in functions and utility class-irrelevant functions to obtain a list of target objects to be tested.

[0054] For example, you can read file content, first use comment exclusion regular expressions to remove all comments; use function matching regular expressions to extract function names; combine function length filtering, such as keeping only functions with more than 3 lines of code, excluding empty functions or minimal functions, to obtain the target object.

[0055] In operation S230, a basic test case template containing input parameter boundary value examples, normal return examples, and abnormal scenario placeholders is generated based on the structural information of the objective function. The basic test case template is then converted into executable test code according to the syntax specifications of the preset underlying unit test framework.

[0056] This operation can generate a basic test case template based on the function structure information parsed by operation S220, which includes examples of input parameter boundary values, normal return examples, and placeholders for abnormal scenarios; the template can then be filled in completely and converted into test code that can be run directly.

[0057] In operation S240, a unit testing system is built, which includes underlying unit testing tools, version difference analysis logic based on the version control system, regular expression matching rules, and test case writing syntax specifications. The basic test case template is generated based on the test case writing syntax specifications and the structural information of the target function.

[0058] In this operation, the underlying unit testing tools can uniformly use a certain tool framework, such as including test execution, assertions, coverage statistics and other capabilities.

[0059] Version difference analysis logic can be based on the difference analysis logic of the version control system, such as: 1. Executing difference analysis commands to obtain the original differences based on the previous version and the current version; 2. Removing differences in comments or configuration files; 3. Filtering out business code files that are only newly added and / or modified.

[0060] Regular expression matching rules can be applied to the primary front-end project, but they are not limited to that project; they can also be applied to other similar front-end projects. Test case writing syntax guidelines can include, for example, the definition of test cases, the usage of assertions, and the usage of exception assertions.

[0061] In operation 250, the target object is tested using a unit testing system.

[0062] This operation is designed for projects that do not integrate a testing framework. It allows for the lightweight construction of a unified unit testing system without modifying the core project configuration. Only test dependencies and configuration files need to be added, and then test cases are written and executed for the target objects. For the units that need test coverage newly added in this release, unit test cases are written in conjunction with the testing framework to complete the unit test coverage of the incremental code.

[0063] For example, a lightweight testing environment can be set up first, and basic test templates can be automatically generated based on the target object. Developers can then add input parameters and expected results. Test cases can be executed, and test reports can be generated. This operation can also call a large model, passing in the function code and business description of the target object, and automatically generating test cases containing normal and / or abnormal scenarios. Developers only need to verify these cases, or the large model can perform the verification itself according to the verification rules.

[0064] This embodiment obtains the incremental code files of the first front-end project through a version control system, uses regular expression matching technology to filter the target objects that need to be unit tested, builds a unit test system adapted to the project, and conducts tests on the target objects. Because it filters incremental code files instead of the full code, accurately identifies the test target objects, and does not rely on a pre-integrated unit test framework, it at least partially solves the problems of large workload, vague test targets, and high difficulty in building a test system for front-end projects without integrated unit test frameworks. It achieves the technical effects of lightweight unit test system construction, efficient and accurate unit testing, and reduced testing implementation costs for front-end projects without integrated test frameworks.

[0065] In some embodiments of this application, obtaining partial code files of a first front-end project based on a version control system includes: executing a difference comparison command of the version control system through a difference comparison process module of a scripting language runtime environment to obtain code difference information between the current release and the previous version; filtering out incremental code added and / or modified in this release based on the code difference information; and constructing partial code files based on files containing incremental code.

[0066] Figure 3 The schematic diagram illustrates the principle of obtaining a portion of the code files of a first front-end project according to an embodiment of this application.

[0067] like Figure 3 As shown, this embodiment uses the G version control system and the N scripting language runtime environment. The first front-end project M contains 3 files (u file, c file and i file). The previous version was v1.0.0, and the current version is v1.1.0.

[0068] Developers write scripts in a scripting language runtime environment. These scripts, through a difference comparison process module (a sub-process module), execute difference comparison commands in the G version control system to compare the code differences between the current release (v1.1.0) and the previous version (v1.0.0). The script then retrieves the code difference information.

[0069] The script parses the code differences described above, filters for valid incremental code according to rules, excludes comments and blank lines, and retains only the newly added and / or modified business logic code. New incremental code, containing the 3 lines of code in function f, is extracted from file u; modified incremental code, containing the 3 new lines of code in function c, is extracted from file c; file i shows no differences and contains no incremental code. The file containing the above incremental code constitutes the partial code file.

[0070] This embodiment automates the execution of version control system difference comparison commands through a subprocess module of the scripting language runtime environment, replacing manual comparison to obtain code difference information. It accurately filters the incremental code and corresponding files added and / or modified in this release, avoiding errors from manual operation and reducing redundant processing in subsequent screening stages, thereby improving the efficiency and accuracy of test scope definition.

[0071] In some embodiments of this application, the method further includes: detecting the target method in the target object that needs to be unit tested in the current version of the code; if the target method is a newly added method that is not recorded in the local file system, then adding a corresponding unit test case record, wherein the local file system records the historical method information that has been unit tested in the first front-end project.

[0072] This embodiment can execute a difference comparison command through the subprocess module of the scripting language runtime environment according to the above embodiments, compare the content of this release with the content of the previous release, and filter out the static files modified in this release by analyzing the output content.

[0073] After filtering the files, the methods that need to be tested by unit testing are matched using regular expressions, and the matched methods are recorded in memory.

[0074] Check if the method was previously recorded in the local file system. If it exists, it means the method has been updated and the test cases need to be rewritten. If it does not exist, it means it needs to be added.

[0075] Check if there is a file in the local file system that records the unit test methods. If so, add the unit test methods to that file. Otherwise, create a new file and add the unit test methods. This can be done using the file system of the scripting language runtime environment.

[0076] In this embodiment, local file system records can typically be stored in the root directory or test directory of the current front-end project. In scenarios where test records are managed uniformly across projects, such as multiple front-end projects in the same business line sharing a test record center, cross-front-end project queries can be achieved by configuring a shared storage directory database at the project group level.

[0077] This embodiment records historical method information that has completed unit testing through the local file system, accurately distinguishes between newly added untested methods and historically tested methods, and only adds test case records for newly added methods. This not only ensures the completeness of test coverage for the core methods of incremental code, but also avoids the rewriting and redundant testing of historical methods, and realizes the synchronous linkage between test cases and code versions, adapting to the iterative needs of agile development.

[0078] In some embodiments of this application, the method further includes: obtaining partial code files of a second front-end project based on a version control system. The second front-end project does not integrate a unit testing framework. The first and second front-end projects have the same underlying core unit testing tools, version control system difference analysis logic, regular expression matching filtering rules, and test case writing syntax specifications, but have different front-end technology architectures or architecture-specific syntaxes. The method further includes: filtering out target objects that need to be unit tested from partial code files of the second front-end project using regular expression matching technology; and testing the target objects of the second front-end project using a unit testing system.

[0079] For example, the first front-end project uses a V architecture, and the second front-end project uses an R architecture; neither has integrated a unit testing framework. The first front-end project uses the underlying testing tool J, uses the d script for difference analysis to filter incremental files, and uses regular expressions to filter by the a regular expression.

[0080] The second front-end project, currently in version v1.1, has two changes compared to the previous version v1.0: a new .u file with the added function 'f'; and a modified .p file with adjustments to the function 'r'. To test the second front-end project, the same 'd' script as the first front-end project was used for difference analysis to filter incremental files, resulting in .u and .p files. Regular expressions 'a' were used to match the newly added function 'f' in the .u file and the modified function 'r' in the .p file. Based on the shared J tool testing framework, test cases were written according to the same syntax as the first front-end project and executed.

[0081] This embodiment addresses the issue of different front-end technology architectures or architecture-specific syntax in multiple projects by uniformly reusing the same underlying unit testing core tools, version difference analysis logic, regular expression matching filtering rules, and test case writing syntax. This shields the impact of architecture differences on the testing system, eliminates the need for customized configuration for each project, significantly reduces the cost of building and maintaining a testing system for multiple architecture projects, and ensures the consistency and standardization of testing logic across multiple projects.

[0082] In some embodiments of this application, target objects that need to be unit tested are selected from a portion of the code files using regular expression matching technology, including: extracting target functions from the target objects that need to be unit tested from the portion of the code files based on regular expression matching technology; storing the target functions in local files and using them to generate corresponding unit test cases.

[0083] Regular expressions can be used to clean up invalid content in code and prevent it from interfering with matching rules. For example, regular expressions can be used to remove single-line comments, multi-line comments, or comments in a certain programming language; remove redundant newlines, consecutive spaces, and tabs to compress the code; and filter out non-function content such as import statements, global variable definitions, or empty code blocks to obtain the target function.

[0084] Figure 4 The flowchart of another front-end integration unit testing method according to an embodiment of this application is illustrated schematically.

[0085] like Figure 4 As shown, the front-end integration unit testing method in this embodiment includes the following steps.

[0086] Use a version control system to retrieve the modified code files from the front-end project. Then, execute a difference comparison command using the scripting language runtime environment's difference comparison process module to compare the current release with the previous release. Analyze the output to identify the modified static files.

[0087] Determine if any files require unit testing: if no, no unit testing is needed; if yes, then filter out the methods that require unit testing. Check if the local file system records the method: if yes, update it by deleting the method from the local file; if no, then record the unit test method to the local file system.

[0088] Based on the records in the local file system, developers write unit test cases, use the unit testing framework to generate reports, and the process ends.

[0089] This embodiment uses regular expression matching technology to accurately extract target functions from incremental code files, focusing on business logic code and avoiding interference from irrelevant code. It provides a clear and traceable basis for test case writing, improves the pertinence and feasibility of test case writing, and solves the problem of traditional testing lacking pertinence.

[0090] In some embodiments of this application, the method further includes: parsing the parameter types, default values, and return value structure of the target function; generating a basic test case template based on the parsing results, wherein the basic test case template contains at least one of input parameter boundary value examples, normal return examples, or abnormal scenario placeholders, and the basic test case template is used to generate corresponding unit test cases.

[0091] For example, a function that calculates the total price based on unit price and quantity might be represented as "return price*num". Upon analysis, the price parameter is of type numeric; the num parameter is of type numeric; the default value for the num parameter is 1; the return value is numeric; and an exception occurs if price is not a numeric value / num < 0.

[0092] The basic test case template can be represented by the following code:

[0093] Define the input constant as `input constant = {price: [example: 100], num: [default value: 1]}`. Define the expected input as `[example: 100]`. Call the target function, passing `price(100)` and `num(1)` from the input, and check if the function's execution result equals `100` in `expected`. `[example: XX]` in the template represents a placeholder; it can be replaced with the actual value later to run the test directly.

[0094] This embodiment automatically generates a basic test case template by parsing the parameter types, default values, and return value structure of the target function. The template includes examples of input parameter boundary values, normal return values, and placeholders for abnormal scenarios. Developers only need to add personalized business logic without having to build a test case framework from scratch. This reduces the technical threshold and workload of test case writing, guides developers to cover key test scenarios, avoids omissions of boundary values ​​and abnormal scenarios, and balances test case writing efficiency with comprehensive test coverage.

[0095] In some embodiments of this application, generating corresponding unit test cases includes: inputting prompt words into a large model, the prompt words instructing the large model to perform the following operations: based on the basic test case template, combined with the business logic of the target function, filling in the appropriate actual values ​​of input parameters, expected return results, or assertion rules for abnormal scenarios; converting the filled basic test case template into executable test code compatible with the syntax of the preset underlying unit test framework; performing syntax verification and logic compatibility verification on the executable test code, correcting content that does not conform to the specifications of the underlying unit test framework or conflicts with the logic of the target function, and obtaining unit test cases.

[0096] Figure 5 The schematic diagram illustrates the principle of generating corresponding unit test cases according to an embodiment of this application.

[0097] like Figure 5 As shown, this embodiment presents the core business function C selected from a front-end project. The underlying testing framework is preset to be J-framework, and a template of J-framework containing placeholders and examples is generated based on function C.

[0098] Input the following prompts into the large model:

[0099] Please strictly follow these three steps to output unit test cases that can be directly executed in the J framework: 1. Fill in the template: Based on the basic test case template below, and combining the business logic of the C function (price / num are numbers, num≥0, return a {totalPrice,discountRate} object, throw an "incorrect parameter format" exception if the parameter is incorrect), fill in the appropriate actual values ​​of the input parameters, the expected return results, and the assertion rules for the exception scenarios. 2. Convert the code: Convert the filled template into executable code that is fully compatible with the syntax of the J testing framework. 3. Verification and correction: Perform syntax verification and logic compatibility verification on the converted code according to the J framework specifications, and correct any non-compliant or conflicting content.

Basic Test Case Template

[0100] The large model executes instructions, fills in placeholders, and converts them into J-framework compatible code, generating preliminary executable code. The large model undergoes verification and correction to finally generate compliant code, resulting in unit test cases.

[0101] This embodiment automates the basic test case template's business logic filling, test framework syntax adaptation and conversion, and code syntax and logic verification and correction through a large model, which greatly improves the efficiency of generating front-end unit test cases. At the same time, it ensures that the cases fit the target function's business logic, are compatible with the unified underlying unit test framework, and are executable.

[0102] Based on the aforementioned front-end integration unit testing method, this application also provides a front-end integration unit testing apparatus. The following will combine... Figure 6 The device is described in detail.

[0103] Figure 6 A schematic block diagram of a front-end integration unit test apparatus according to an embodiment of this application is shown.

[0104] like Figure 6 As shown, the front-end integration unit testing device 600 of this embodiment includes an incremental code acquisition module 610, a target object filtering module 620, and a test system construction module 630.

[0105] The incremental code acquisition module 610 is used to acquire the code files of the first front-end project based on the version control system. The first front-end project does not integrate a unit testing framework, and the code files at least include the incremental code files added and / or modified in this release.

[0106] The target object filtering module 620 is used to extract the target functions that need to be unit tested from the code file by using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project technical architecture, and to parse and obtain the parameter types, default values ​​and return value structures of the target functions.

[0107] The test system building module 630 is used to generate a basic test case template containing input parameter boundary value examples, normal return examples, and abnormal scenario placeholders based on the structural information of the target function, and to convert the basic test case template into executable test code according to the syntax specifications of the preset underlying unit test framework; to build a unit test system including underlying unit test tools, version difference analysis logic based on the version control system, the regular expression matching rules, and test case writing syntax specifications, wherein the basic test case template is generated based on the test case writing syntax specifications combined with the structural information of the target function; and to test the target function using the unit test system.

[0108] According to an embodiment of this application, the incremental code acquisition module 610 is further configured to execute the version control system's difference comparison command through the difference comparison process module of the scripting language runtime environment to obtain code difference information between the current release and the previous version; based on the code difference information, filter out the incremental code added and / or modified in this release; and construct a code file based on the file containing the incremental code.

[0109] According to an embodiment of this application, the test system building module 630 is also used to detect the target method in the target object that needs to be unit tested in the current version of the code; if the target method is a newly added method that is not recorded in the local file system, then a corresponding unit test case record is added, wherein the local file system records the historical method information that has been unit tested in the first front-end project.

[0110] According to an embodiment of this application, the incremental code acquisition module 610 is further used to acquire the code files of the second front-end project based on the version control system. The second front-end project does not integrate a unit testing framework. The first front-end project and the second front-end project have the same underlying unit testing core tools, version control system difference analysis logic, regular expression matching filtering rules and test case writing syntax specifications, but have different front-end technology architectures or architecture-specific syntax. The target object filtering module 620 is further used to filter out the target objects that need to be unit tested from the code files of the second front-end project through regular expression matching technology. The test system building module 630 is further used to test the target objects of the second front-end project using the unit testing system.

[0111] According to an embodiment of this application, the target object filtering module 620 is further used to extract the target function in the target object that needs to be unit tested from the code file based on regular expression matching technology; store the target function in a local file and use it to generate corresponding unit test cases.

[0112] According to an embodiment of this application, the test system building module 630 is further used to parse the parameter types, default values, and return value structure of the target function; based on the parsing results, a basic test case template is generated. The basic test case template includes at least one of the following: input parameter boundary value examples, normal return examples, or abnormal scenario placeholders. The basic test case template is used to generate corresponding unit test cases.

[0113] According to an embodiment of this application, the test system building module 630 is further used to input prompt words into the large model. The prompt words instruct the large model to perform the following operations: based on the basic test case template and combined with the business logic of the target function, fill in at least one of the assertion rules of the actual value of the input parameter, the expected return result, or the abnormal scenario; convert the filled basic test case template into executable test code compatible with the syntax of the preset underlying unit test framework; perform syntax verification and logic compatibility verification on the executable test code, correct the content that does not conform to the specifications of the underlying unit test framework or conflicts with the logic of the target function, and obtain unit test cases.

[0114] According to embodiments of this application, any multiple modules among the incremental code acquisition module 610, target object screening module 620, and test system construction module 630 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the incremental code acquisition module 610, target object screening module 620, and test system construction module 630 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented by any other reasonable means of integrating or packaging the circuit, or implemented by any one of software, hardware, and firmware, or by a suitable combination of any of these. Alternatively, at least one of the incremental code acquisition module 610, target object screening module 620, and test system construction module 630 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0115] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a front-end unit testing method according to an embodiment of this application.

[0116] like Figure 7As shown, an electronic device 700 according to an embodiment of this application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage portion 708 into a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0117] RAM 703 stores various programs and data required for the operation of electronic device 700. Processor 701, ROM 702, and RAM 703 are interconnected via bus 704. Processor 701 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 702 and / or RAM 703. It should be noted that the programs may also be stored in one or more memories other than ROM 702 and RAM 703. Processor 701 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0118] According to embodiments of this application, the electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0119] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0120] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 702 and / or RAM 703 and / or one or more memories other than ROM 702 and RAM 703 described above.

[0121] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the front-end integration unit testing method provided in the embodiments of this application.

[0122] When the computer program is executed by the processor 701, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0123] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0124] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0125] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, p7thon, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0126] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0127] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this application can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments and / or claims of this application can be combined or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0128] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this application is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this application, and all such substitutions and modifications should fall within the scope of this application.

Claims

1. A front-end integration unit testing method, comprising: The code files of the first front-end project are obtained based on the version control system. The first front-end project does not integrate a unit testing framework. The code files contain at least the incremental code files added and / or modified in this release. By using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project's technical architecture, the target function that needs to be unit tested is extracted from the code file, and the structural information of the target function is obtained by parsing. Based on the structural information of the objective function, a basic test case template is generated, which includes examples of input parameter boundary values, normal return examples, and placeholders for abnormal scenarios. The basic test case template is then converted into executable test code according to the syntax specifications of the preset underlying unit test framework. A unit testing system is built, which includes underlying unit testing tools, version difference analysis logic based on the version control system, regular expression matching rules, and test case writing syntax specifications. The basic test case template is generated based on the test case writing syntax specifications and the structural information of the target function. The objective function is tested using the aforementioned unit testing system.

2. The method according to claim 1, characterized in that, The process of obtaining the code files of the first front-end project based on the version control system includes: The difference comparison process module of the scripting language runtime environment executes the difference comparison command of the version control system to obtain the code difference information between the current release and the previous version. Based on the code difference information, the incremental code added and / or modified in this release is selected; The code file is constructed based on the file containing the incremental code.

3. The method according to claim 1, further comprising: Detect the target methods in the target objects that require unit testing in the current version of the code; If the target method is a newly added method that is not recorded in the local file system, then a corresponding unit test case record is added. The local file system records the historical method information that has been tested in the first front-end project.

4. The method according to claim 1, characterized in that, Also includes: Based on the version control system, a portion of the code files of the second front-end project are obtained. The second front-end project does not integrate a unit testing framework. The first front-end project and the second front-end project have the same underlying unit testing core tools, version control system difference analysis logic, regular expression matching filtering rules and test case writing syntax specifications, as well as different front-end technology architectures or architecture-specific syntax. The target objects that need to be unit tested are filtered out from some code files of the second front-end project using the regular expression matching technique. The target object of the second front-end project is tested using the unit testing system.

5. The method according to claim 1, characterized in that, The step of filtering out target objects for unit testing from the code file using regular expression matching technology includes: Based on the regular expression matching technique, the target function in the target object that needs to be unit tested is extracted from the code file; The target function is stored in a local file and used to generate corresponding unit test cases.

6. The method according to claim 1, characterized in that, The generation of corresponding unit test cases includes: Input a prompt word into the large model, the prompt word instructing the large model to perform the following operation: Based on the aforementioned basic test case template, and combined with the business logic of the target function, fill in at least one of the assertion rules for the actual value of the input parameter, the expected return result, or the abnormal scenario. Convert the populated basic test case template into executable test code that is compatible with the syntax of the preset underlying unit testing framework; The executable test code is subjected to syntax verification and logic compatibility verification. Content that does not conform to the underlying unit test framework specification or conflicts with the target function logic is corrected to obtain the unit test case.

7. A front-end integrated unit test apparatus, comprising: The incremental code acquisition module is used to acquire the code files of the first front-end project based on the version control system. The first front-end project does not integrate a unit testing framework. The code files at least include incremental code files added and / or modified in this release. The target object filtering module is used to extract target functions to be unit tested from the code file by using regular expression matching rules that at least adapt to the function definition syntax of the first front-end project's technical architecture, and to parse and obtain the parameter types, default values, and return value structures of the target functions; and The test system construction module is used to generate basic test case templates containing input parameter boundary value examples, normal return examples, and abnormal scenario placeholders based on the structural information of the target function, and to convert the basic test case templates into executable test code according to the syntax specifications of the preset underlying unit test framework; to build a unit test system including underlying unit test tools, version difference analysis logic based on the version control system, the regular expression matching rules, and test case writing syntax specifications, wherein the basic test case templates are generated based on the test case writing syntax specifications combined with the structural information of the target function; and to test the target function using the unit test system.

8. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images