Object instantiation code generation method, apparatus, device, and medium

Abstract

The application relates to the technical field of test cases and discloses an object instantiation code generation method, device, equipment and medium, which comprises the following steps: constructing structured data based on parameter data generated by a running environment, generating an initialization code segment in combination with class structure information of a target parameter model, forming an object initialization statement block through splicing, scanning the object initialization statement block, generating a corresponding dependent introduction statement block, and outputting complete code text. The application can be applied to business scenarios such as financial technology and medical health, object initialization code is generated based on real parameter data of a running environment, test input parameters are closer to actual business scenarios, a matching dependent introduction statement block is automatically generated, the incompleteness of manually constructed input parameters is reduced, and the coverage of a unit test scenario and the code availability are improved.

Description

Technical Field

[0001] This invention relates to the field of test case technology, and in particular to a method, apparatus, device, and medium for generating object instantiation code. Background Technology

[0002] In software development, unit testing is typically used to verify the correctness of the smallest functional unit under different input conditions. The completeness and authenticity of the input parameters in test cases directly affect the reliability of the test results. Currently, the construction of unit test input parameters mostly relies on manual coding, with developers selecting and assigning values ​​to certain fields based on experience. This approach struggles to accurately reflect the actual data format generated in the runtime environment when dealing with complex, nested, and multi-type object input parameters, easily leading to insufficient test scenario coverage and causing some potential problems to go undetected during the testing phase.

[0003] In the fintech business, software systems widely involve core business logic such as transaction processing, account management, fund clearing, risk control, and claims settlement, requiring high levels of structural integrity and field consistency in method input parameters. The input parameters of related business code typically consist of multiple related objects, collection structures, and various field types, with clear dependencies between different fields. In current unit testing practices, input parameters are often constructed manually, and test data is mostly simplified examples, failing to cover the complex data combinations in real-world transaction, risk control, or settlement scenarios. This leads to discrepancies between test results and the actual operating environment, increasing the risk of business anomalies in the production environment.

[0004] In the healthcare business domain, software systems need to process multi-source structured data such as patient information, medical records, examination results, and medication plans. These data objects typically have a clear hierarchical structure and strict field constraints. During unit testing, the input parameters also need to fully reflect the real business data structure. However, current technologies lack effective mechanisms for obtaining and reproducing input parameters from actual method calls in the runtime environment. Test data is often manually constructed, making it difficult to accurately reproduce the nested relationships and field combinations of complex medical data, thus reducing the ability of unit tests to discover real business problems. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for generating object instantiation code. This invention aims to solve the technical problem in the prior art where unit test input parameters mainly rely on manual construction, making it difficult to realistically reproduce the complex object structures and field combinations generated by method calls in the runtime environment, resulting in insufficient test scenario coverage and test results deviating from actual business operations.

[0006] To achieve the above objectives, the present invention provides a method for generating object instantiation code, comprising: Obtain the input parameter data generated by the operating environment and save the input parameter data as a structured data file; Read the structured data file and parse the structured data file to construct a data node tree; Obtain the target parameter model, and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism; Based on the class structure information, the data node tree is recursively traversed, and corresponding initialization code snippets are generated according to the field type; The initialization code fragments are assembled to generate an object initialization statement block; Scan the object initialization statement block to extract all class identifier text, and perform deduplication on the all class identifier text to generate dependency class information; Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0007] Furthermore, to achieve the above objectives, the present invention provides an object instantiation code generation apparatus, comprising: The input parameter acquisition and disk storage module is used to acquire input parameter data generated by the operating environment and save the input parameter data as a structured data file; The structured data parsing and tree building module is used to read the structured data file and parse the structured data file to build a data node tree; The class structure extraction module is used to obtain the target parameter model and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism. The code snippet generation module is used to recursively traverse the data node tree based on the class structure information and generate corresponding initialization code snippets according to the field type; The statement block assembly module is used to assemble the initialization code fragments to generate object initialization statement blocks; The dependency class information generation module is used to scan the object initialization statement block to extract all class identifier text, and perform deduplication operation on the all class identifier text to generate dependency class information; The dependency import output module is used to generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and an object instantiation code generation program stored in the memory and executable on the processor, wherein when the object instantiation code generation program is executed by the processor, it implements the steps of the object instantiation code generation method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing an object instantiation code generation program, wherein the object instantiation code generation program, when executed by a processor, implements the steps of the object instantiation code generation method as described above.

[0010] Beneficial Effects: This invention relates to the field of test case technology and discloses a method, apparatus, device, and medium for generating object instantiation code. The method includes: structuring and parsing parameter data generated by the runtime environment into a hierarchical data node structure, generating corresponding initialization code fragments by combining the class structure information of the target parameter model, assembling the initialization code fragments to form object initialization statement blocks, scanning the object initialization statement blocks to generate matching dependency import statement blocks, and finally outputting code text containing dependency import statement blocks and object initialization statement blocks. This invention can be applied to business scenarios such as fintech and healthcare. By utilizing real parameter data generated in the runtime environment to construct object initialization code, it reduces subjective omissions caused by manually constructing test input parameters, making the generated test code more closely resemble actual business scenarios in terms of structure and field combinations. Simultaneously, it automatically generates dependency import statement blocks that match the initialization code, ensuring the integrity and consistency of the output code, thereby improving the accuracy of unit test input parameter construction and scenario coverage. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for an object instantiation code generation method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the object instantiation code generation method of the present invention; Figure 3 A schematic diagram of functional modules of a preferred embodiment of the object instantiation code generation device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The object instantiation code generation method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can use the parameter data generated by the client based on the runtime environment to structure and parse the parameter data into a hierarchical data node structure. Combined with the class structure information of the target parameter model, it generates corresponding initialization code snippets. These initialization code snippets are then assembled to form object initialization statement blocks. These object initialization statement blocks are scanned to generate matching dependency import statement blocks, ultimately outputting code text containing both dependency import statement blocks and object initialization statement blocks. This invention can be applied to business scenarios such as fintech and healthcare. By utilizing real parameter data generated in the runtime environment to construct object initialization code, it reduces subjective omissions caused by manually constructing test input parameters, making the generated test code more closely resemble actual business scenarios in terms of structure and field combinations. Simultaneously, it automatically generates dependency import statement blocks that match the initialization code, ensuring the integrity and consistency of the output code, thereby improving the accuracy and scenario coverage of unit test input parameter construction. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the object instantiation code generation method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the object instantiation code generation method proposed in this invention includes the following steps: S10, acquire the input parameter data generated by the operating environment, and save the input parameter data as a structured data file; In this embodiment, the runtime environment refers to the actual computing context in which the software application is deployed and executed. It consists of the operating system, runtime library, configuration parameters, and the real business load being processed. During continuous operation, the application responds to external requests or internal events, calling various internally defined functional methods. Each call generates an execution trajectory containing specific input parameter values. For example, in the fintech business field, a microservice that handles credit approval is a runtime environment. When it receives a loan application, it calls a risk scoring method, passing in the applicant's information, loan amount, etc., as parameters. Input parameter data is the set of data actually passed to the target method when these specific calls occur. It directly reflects the form of real business information circulating in the production or testing environment. Obtaining input parameter data means actively locating and reading these historical records from the persistent storage of the runtime environment. In implementation, this can be done by accessing application log files, which typically record method signatures and parameters in text form; querying specific audit tables in the business database, which may store the request load of each service call; or listening to message queues or event buses to capture real-time business messages flowing through the system. Saving the obtained input parameter data as a structured data file is a process of format conversion and persistence. First, the raw data (which could be text log lines, database records, or serialized message bodies) needs to be interpreted and the pure data portion extracted. Then, it needs to be reorganized and serialized according to a data exchange format with self-descriptive and hierarchical syntax rules. For example, transaction request data extracted from a payment gateway log can be converted into a file conforming to the JSON format specification. This file clearly distinguishes fields such as transaction serial number, timestamp, payment amount, payee object, and their nested relationships. Finally, through file system write operations or cloud storage service upload interfaces, the serialized byte stream is output to a specific location on disk or network storage, forming a structured data file that can be independently accessed by subsequent processing.

[0016] The specific source for obtaining input parameter data can be adapted to the system architecture. In environments with centralized log management, parameters can be extracted from log platforms such as Elasticsearch or Splunk by querying specific method names and time ranges. For business systems that store request parameters in relational databases, historical records can be retrieved by executing SQL queries. In event-driven architectures, data can be obtained by replaying historical messages on specific topics in message brokers such as Kafka or RabbitMQ. The choice of structured data file format is flexible. In addition to the widely used JSON, XML can be used to support stricter schema validation, YAML can be used to improve human readability, and binary serialization formats such as Protocol Buffers or Avro can be used to improve storage and transmission efficiency. The location and method of saving files also vary depending on the deployment environment. In local development or testing environments, files can be written directly to a specified folder under the project directory. In continuous integration pipelines, files can be stored in a build artifact repository. In cloud-native environments, files can be saved to object storage services such as Amazon S3, Google Cloud Storage, or Alibaba Cloud OSS and distributed via access links. For financial scenarios with high data security requirements, the saving process can integrate an encryption module to encrypt sensitive fields before writing.

[0017] This embodiment extracts input parameter data generated from real business interactions in the actual operating environment and standardizes it into structured files, providing high-quality, production-realistic input materials for the subsequent automated code generation process. This avoids the subjectivity, bias, and unavoidable omissions that arise from relying entirely on manually fabricated and spelled test data by developers, ensuring the fundamental quality of test data in terms of business logic coverage and data format authenticity, thus laying the foundation for building highly reliable unit tests.

[0018] S20, read the structured data file and parse the structured data file to construct a data node tree; In this embodiment, reading a structured data file is an input / output operation on a file system or storage service, the purpose of which is to load persistently stored formatted text content into the application's available memory space. This process begins by locating the target file entity based on the file path or Uniform Resource Identifier, and then establishing a data reading channel from the application to the file. Through this channel, the raw byte sequence contained in the file can be obtained in a sequential or random access manner. To correctly process human-readable text content, the byte sequence needs to be decoded into a complete text string conforming to standards such as Unicode, according to the character encoding rules declared or pre-agreed upon by the file itself. Parsing the structured data file is a computational process of understanding and transforming the text string in a structured way. The parser first performs a lexical scan on the continuous text string, identifying and segmenting the smallest units with independent syntactic meaning, such as curly braces that identify the beginning and end of objects, colons that separate key-value pairs, text enclosed in quotation marks representing strings, numeric literals, and Boolean values. These lexical units form a sequence in the order of their appearance. Subsequently, the syntax analysis component processes this sequence of lexical units according to the syntax rules of the target data format. For example, in JSON format, the analysis process identifies object definitions, array structures, and nested key-value pair relationships, verifies bracket matching and structural integrity, and constructs an intermediate representation structure that reflects the complete hierarchy and type information of the original data. Building the data node tree involves instantiating a tree-like data structure in memory based on the parsed structural information, facilitating program traversal and manipulation. This process creates a corresponding node object for each logical data unit in the parsed intermediate representation. Each node object records its type, key name, value, or references to other nodes. Based on the parent-child containment relationships determined during parsing, these node objects are linked together. The root node represents the outermost object or array, and child nodes represent their internal attributes or elements, thus forming a data node tree that completely maps the original file's data hierarchy and content in memory.

[0019] The implementation of file reading varies depending on the deployment environment. In standard server or desktop environments, synchronous or asynchronous reading can be performed using the local file system API provided by the operating system. In containerized or cloud function environments, files may reside on mounted volumes or be accessed via a network file system, requiring adaptation to the corresponding client library. For files stored in object storage services, the content must be downloaded via HTTP using the service's SDK. Character encoding processing must be robust, with UTF-8 preferred, while also supporting BOM header detection and processing or fallback to other common encodings. The parsing process can utilize various technologies, including mature open-source libraries such as Jackson, Gson, or Json.NET for JSON, and DOM or SAX parsers for XML. Alternatively, a custom parser can be developed based on syntax generation tools like ANTLR to handle domain-specific formats. When constructing the data node tree, the specific implementation structure of the nodes can be adjusted, employing a general combination of Map and List, or defining domain-specific objects with strongly typed properties. The tree structure construction algorithm can be recursive or iterative to accommodate data of varying depth and breadth. To improve the performance of processing large files, a combination of streaming parsing and lazy loading can be used, where the corresponding node is built only when a specific subtree is accessed.

[0020] This embodiment automates the reading and parsing of structured data files, accurately transforming them into a data node tree with a clear hierarchical relationship in memory. This lays a reliable foundation for subsequent automated logic processing based on the data structure. This process eliminates the need for manually reading complex data file formats, understanding their nested relationships, and writing code to construct the corresponding data model. It ensures that the conversion of data from persistent storage to the in-memory computing model is accurate, efficient, and reproducible, providing structured input for generating code that highly matches the original data structure.

[0021] S30, obtain the target parameter model, and extract the class structure information contained in the target parameter model through the dynamic structure acquisition mechanism; In this embodiment, the target parameter model refers to the programmatic definition of the specific category that needs to be instantiated and populated with data. It specifies the set of attributes, data types, and internal structure that the final generated object should possess. In object-oriented programming paradigms, a model typically corresponds to a class that defines the various fields and type constraints that constitute the business entity. For example, in fintech business, the target parameter model might be a "LoanApplication" class, which defines fields such as applicantName (string), requestedAmount (numerical), creditScore (numerical), and collateralList (object list). Obtaining the target parameter model means explicitly specifying the identifier of this class during code generation, usually through its fully qualified class name, which uniquely identifies the class's location in the classpath or module system. The dynamic structure acquisition mechanism is the ability of a program to dynamically query, inspect, and manipulate its own structure at runtime rather than compile time, which is manifested as the reflection application programming interface in many programming languages. Through this mechanism, the program can load a specified class and traverse its metadata. Extracting class structure information is a specific application of the reflection mechanism, aiming to obtain a complete blueprint of the class. This includes retrieving the definitions of all fields declared in the class, recording the name, declared data type, and access modifier of each field; retrieving the signatures of all constructors defined in the class, including the parameter type list; and retrieving all methods defined in the class for accessing field values, typically referring to getter and setter methods that follow a specific naming convention. In implementation, firstly, based on the provided classpath identifier, the class loader loads the target class into the memory of the currently running Java Virtual Machine. Then, the Class object representing the class is obtained through the reflection API. Using this Class object, the `getDeclaredFields` method is called to obtain an array of Field objects, extracting the field name, type, and modifier from each Field; the `getDeclaredConstructors` method is called to obtain an array of Constructor objects; and the `getDeclaredMethods` method is called to obtain an array of Method objects, filtering out methods that conform to the getter / setter naming pattern. Finally, all the collected metadata information is organized into a structured information set, which fully describes the internal structure of the target class.

[0022] The methods for obtaining model identifiers can be adapted to different scenarios. In integrated development environment (IDE) plugins, class names can be obtained by parsing user-selected code elements. In command-line tools, class paths can be read via command-line arguments or configuration files. In web services, class names can be received through API request bodies. The implementation of dynamic structure retrieval mechanisms depends on the specific programming language and runtime. In the Java platform, the `java.lang.reflect` package is used; in C#, the `System.Reflection` namespace is used; in Python, the `inspect` module can be used; in JavaScript / TypeScript, decorators or compile-time metadata reflection APIs can be utilized. For fields with different visibility, the reflection mechanism can be configured to access private or protected members. Class loading strategies can be adjusted, such as using the current thread's context class loader, the system class loader, or a custom class loader, to accommodate the need to load classes from different modules or JAR files. The information extraction process can be optimized through caching, storing the parsed class structure information in a memory cache to avoid repeated reflection operations on the same class, thus improving performance.

[0023] This embodiment automatically extracts the complete class structure information of the target parameter model through a dynamic structure acquisition mechanism, providing a precise blueprint for subsequently mapping data nodes to specific object fields and generating type-safe code. This process eliminates the tedious and error-prone work of manually reviewing class definition files and manually recording fields and their types, ensuring that the generated initialization code is strictly consistent with the target class in terms of field names, data types, and access methods, avoiding code defects such as attribute mismatches and type conversion errors caused by manual errors or omissions.

[0024] S40, recursively traverse the data node tree according to the class structure information, and generate corresponding initialization code snippets according to the field type; In this embodiment, the class structure information provides a precise blueprint of the target model, defining the name of each field and its category in the programming language type system. Recursive traversal is an algorithmic strategy that systematically visits each node, starting from the root node of the data node tree, following a depth-first approach. When visiting each node, the key name represented by the node is matched against the field names defined in the class structure information to determine which specific field in the model is currently being processed. Once a field is determined, its data type declared in the blueprint is queried. The field type is a critical branching point in determining how the code is generated. For basic data types, such as integers, floating-point numbers, strings, or booleans, the processing logic is straightforward. The system retrieves the stored value from the currently accessed data node and then constructs a statement to assign the value to the field according to the programming language's syntax rules. For object type fields, this means that the field's value itself is another complex object with an internal structure. At this point, the recursive traversal algorithm enters the sub-data node tree represented by the current node and, guided by the class structure information corresponding to the nested object (which can be obtained from the original class structure information or dynamically again), continues to perform the same traversal and generation process on its subtree. The result of this deep traversal is a code block describing how to initialize the nested object; this code block is considered an independent, embeddable fragment. For collection type fields, such as lists or arrays, the processing logic consists of two parts. First, code is generated to create the collection container itself. Then, the child nodes representing collection elements under the current data node are traversed, generating code to add each element to the container. The element itself may be a basic type value, a nested object, or a nested collection, requiring the recursive application of the same type checking and generation logic. Ultimately, everything generated for each node in the tree—whether a simple assignment statement, a nested object initialization code block, or a collection creation and filling statement—is collectively referred to as an initialization code fragment. These fragments are discrete code units reflecting local data relationships, providing standardized building blocks for subsequent assembly into complete object construction logic.

[0025] The specific implementation of the recursive traversal algorithm can be adjusted. Function recursion supported by the system call stack can be used, which is concise but may pose a stack overflow risk for extremely deep data trees. Alternatively, an explicit stack data structure can be used for iterative depth-first traversal, providing more stable memory usage. Field type matching and dispatch logic can be implemented using the strategy pattern, registering an independent code generation processor for each major type. Code snippet generation methods are diverse. String concatenation can be used to construct lines of code. A template engine can be used to predefine code templates for different field types and then perform variable substitution. Abstract syntax tree nodes can also be constructed and then uniformly converted to text. For generic collection types, specific element type parameters need to be parsed and embedded during generation. When handling complex object graphs that may contain circular references, the traversal logic needs to integrate a reference detection mechanism, using identifier mapping to avoid infinite recursion and potentially generating code that references the same object instance.

[0026] This embodiment achieves automated conversion from structured data to type-safe, structure-matched object construction code by recursively traversing the data node tree using class structure information as a blueprint and dynamically generating corresponding initialization code snippets based on field types. This process accurately handles different scenarios such as basic assignment, object nesting, and collection initialization, ensuring that the generated code can completely and correctly reflect the complex hierarchical relationships and type constraints of the original data, and completely replacing the structural misunderstandings, type errors, and nesting omissions that are very likely to occur when manually writing such code.

[0027] S50, the initialization code fragments are assembled to generate an object initialization statement block; In this embodiment, the initialization code fragment is a collection of discrete code units generated by the preprocessing steps. These units correspond to the assignment logic of different fields in the target object, specifically including statements that directly assign values ​​to basic type fields, code blocks describing the internal structure of nested objects, and combinations of statements that create collections and add elements to them. Assembly refers to a systematic process of organizing, syntactically integrating, and structurally encapsulating these scattered and disordered code fragments. This process first requires determining the logical position and order of each code fragment in the final code block based on the original hierarchical relationship and occurrence order implied by the data node tree, ensuring that the generated code semantically correctly reflects the original structure of the data. Subsequently, a statement for creating a new instance of the target class needs to be generated, for example, in Java, corresponding to "new ClassName()". This statement constitutes the starting point of the entire initialization logic. Next, a syntax symbol indicating the start of the code block, such as a left curly brace, needs to be added after the instantiation statement. Then, in a predetermined order, all code fragments are sequentially embedded after the starting symbol, with each fragment typically separated by a newline character, and appropriate indentation whitespace characters added according to its nesting level to maintain code readability. Once all the code snippets are embedded, a syntax symbol indicating the end of the code block, such as a closing brace, needs to be added. Finally, the instantiation statement, the start symbol, the ordered sequence of code snippets, and the end symbol are combined into a complete, coherent text block that conforms to the target programming language's syntax. This text block is the object initialization statement block, which contains all the executable instructions needed to instantiate the object and assign specific values ​​to all its fields.

[0028] The assembly strategy and implementation methods can be selected and adjusted according to actual needs and technical environment. The order of code snippets can be strictly determined by the depth-first traversal of the data node tree, which most naturally reflects the original nesting level of the data; alternatively, they can be arranged alphabetically by field names to produce uniformly formatted code. Code snippets can be combined directly using string concatenation. For a large number of snippets, using StringBuilder or similar mutable string containers can improve performance and reduce memory overhead. If strict formatting requirements are placed on the generated code, a third-party code formatting library can be integrated to perform standard indentation and line breaks on the overall text after concatenation. The assembly process can also be based on template technology, predefining a code framework template containing placeholders and then filling the code snippets as variables into the corresponding positions. For scenarios generating code in different programming languages, different syntax rules need to be adapted. For example, instantiation statements may differ in C#, while semicolons and curly braces are not required in Python. To handle potential circular references, the assembly logic can introduce a mechanism for generating and managing temporary variable identifiers.

[0029] This implementation automates the orderly assembly of discrete initialization code fragments according to the original data structure, generating syntactically complete and formatted object initialization statement blocks. This completely eliminates the unavoidable syntax errors and formatting problems such as disordered order, missing brackets, and inconsistent indentation that are inevitable when manually writing complex object construction code. It ensures the immediate usability and maintainability of the generated code and significantly improves the overall quality of test code and development efficiency.

[0030] S60, Scan the object initialization statement block to extract all class identifier text, and perform deduplication on the all class identifier text to generate dependency class information; In this embodiment, the object initialization statement block is a continuous text generated by the aforementioned process, conforming to the syntax rules of a specific programming language. Its content includes a series of statements that instantiate a target class using the `new` keyword and assign values ​​to the various fields of that instance. This text block is a complete description of the programmatic construction of a complex data structure, which inevitably references multiple different classes. These classes include the instantiated target class itself, classes defined in its field types, classes appearing as parameters or return values ​​in assignment statements, and classes declared in collection element types. Scanning the object initialization statement block refers to the systematic analysis and pattern recognition of this code text. Implementing this process typically requires loading a series of predefined syntax matching rules, which describe common syntax patterns for referencing a class in the target programming language. For example, in Java, class references may appear after the `new` keyword (instantiation), within type casting brackets, as the receiver of a static method call, or as the declaration type of a variable. The scanning process examines the code text line by line or word by word, comparing text fragments with these syntax patterns to identify all character sequences that conform to the syntax characteristics of class references. Extracting the full class identifier text involves extracting the specific class name string from each identified syntax pattern. For example, extracting `Transaction` from `new Transaction()`, `Account` from `(Account) someObject`, and `CurrencyFormatter` from `CurrencyFormatter.format()`. During extraction, any accompanying generic parameters (such as `List`) need to be handled. <string>Extracting List and String classes and ignoring language keywords, all extracted class name strings are temporarily collected into a set, forming a complete set of class identifier text. This set directly reflects all external classes that the initialization code depends on. Deduplication of the complete class identifier text is performed based on the characteristics of the set data structure, automatically eliminating duplicate class names. Specifically, all collected class name strings can be added one by one to a hash set. The characteristics of this data structure guarantee the uniqueness of its internal elements, thus naturally filtering out duplicates. Generating dependency class information is a further organization and enrichment of the unique class name set obtained after deduplication. This process not only retains the class names but may also determine the complete package reference path to which each class name belongs by querying the classpath, module system, or a pre-defined mapping table. Finally, these class names and their corresponding package path information are encapsulated into a structured data object or ordered list. This structured information is the dependency class information, which clearly lists all external types imported or referenced and their sources required to construct the current object initialization block.

[0031] The specific techniques for scanning and extraction can be chosen based on the required depth of code text analysis. Lightweight text matching based on regular expressions can be used, which is fast and suitable for scenarios with relatively fixed syntax. To more accurately identify complex syntactic structures, a lexical analyzer and a simple parser can be integrated to construct a lightweight abstract syntax tree (AST), and then the AST nodes can be traversed to extract type information. In the context of an integrated development environment (IDE) or build toolchain, the compiler's API can be directly used to obtain the semantic information of the code, thereby achieving the highest accuracy in class reference identification. Different data structures can be chosen for deduplication, such as using a HashSet to ensure uniqueness using a hash table, or using a TreeSet to automatically sort while deduplicating. For large-scale code collections, the deduplication process can be combined with a Bloom filter for initial, fast deduplication. When generating dependency class information, the method for determining package paths can be varied. Classes can be loaded and their package names obtained through reflection; the dependency management files of the project (such as Maven's pom.xml, Gradle's build.gradle) can be parsed to establish a mapping from class names to package names; or a predefined mapping table of commonly used library package names can be maintained. In cloud-native or microservice architectures, this process can be combined with service discovery or component repository metadata queries.

[0032] This embodiment automatically scans and extracts class references from the generated code text, and then deduplicates and structures it to generate dependency class information. This ensures that all type declarations required by the final output code block are automatically and accurately added. This process avoids omissions or errors that are easily missed when manually checking code and listing required import statements, ensuring the integrity and compilability of the generated code, and further improving the end-to-end reliability of the automated process from data to executable test code.

[0033] S70, Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0034] In this embodiment, dependency class information is a structured data collection that systematically lists all external types referenced in object initialization blocks and associates the complete package reference path for each type in the library or module system. This information originates from semantic analysis of the generated code text and is the necessary list of external references for building independently compileable code units. Generating dependency import blocks is a code synthesis process, the core of which is to convert abstract dependency metadata into concrete lines of source code conforming to the syntax of a specific programming language. In implementation, the system iterates through each record in the dependency class information, instantiating each unique class identifier and its corresponding package path according to a predefined statement template in the target language. For example, in a Java context, this would generate a statement like `import com.domain.package.ClassName;`. These independently generated single-line statements then need to be integrated into a syntactically correct and well-formed code block. Integration typically involves sorting the statement set; a common strategy is lexicographical sorting based on the complete strings of package and class names, which helps improve the structural clarity and maintainability of the generated code. After sorting, newlines are inserted between the statements, and consistent indentation is added according to coding standards, ultimately forming a coherent block of dependency import statements. Outputting the dependency import statement block and object initialization statement block is the final stage of delivering the final result. This operation spatially combines the previously generated dependency import statement block with the already constructed object initialization statement block. Standard code organization conventions place dependency declarations at the top of the file; therefore, the dependency import statement block is placed at the beginning of the combined output, followed immediately by the object initialization statement block, typically separated by a blank line. The generated complete text content is then directed to a specified output channel, such as being written to a new .java source code file via a file input / output stream, printed to the command-line console via standard output stream, or returned to the caller via an application programming interface, thus completing the fully automated delivery chain from data to executable test code.

[0035] The syntax for generating dependency import statements can be adapted to different programming languages ​​and module systems. For Java projects, standard import statements can be generated; for projects using the Java Platform Module System, require directives may need to be generated in the module description file; for Scala or Kotlin, their respective import syntax must be followed. The sorting logic can be customized, including simple lexicographical order, grouping by package name hierarchy, or separating imports of internal modules from those of third-party libraries. Formatting details can be adjusted, such as whether to use static imports, whether to allow wildcard imports, and whether to use spaces or tabs for indentation. The output phase offers broader technical adaptability. In continuous integration environments, generated code can be directly written to the test directory of the source code repository. In interactive development tool plugins, code can be output to a specific window in the editor for developers to review and insert. In service-oriented architectures, code blocks can be returned to the client via HTTP responses. For large generation tasks, output can be streamed in chunks. In financial systems requiring high security, the output process can integrate code scanning or static analysis to perform security checks on the generated code before writing.

[0036] This embodiment automatically generates well-formatted dependency import statements based on dependency class information and systematically combines them with object initialization statements for output. This ensures that the final delivered code is not only fully functional but also directly compileable and integrable. This process eliminates problems such as path errors, missing dependencies, and formatting issues that are prone to occur when manually writing and managing import statements, guaranteeing the industrial-grade quality and reliability of the automatically generated code, and enabling the generated test code to be seamlessly integrated into the existing project build system.

[0037] In one embodiment, step S10 includes: S101, locate the persistent data source that stores method call records in the runtime environment; S102, Based on the unique identifier of the target method, filter out the set of records containing the target method call information from the persistent data source; S103, extract the original parameter data corresponding to each call from the record set; S104, Perform format unification and redundancy cleanup operations on the original parameter data to generate standardized input parameter data; S105, the standardized input parameter data is serialized into structured text data according to preset key-value pairs and hierarchical nesting rules; S106, the structured text data is written to a specified file path on the local disk to generate a structured data file.

[0038] In this embodiment, the runtime environment generates a large amount of data recording the execution trajectory of its internal methods during the continuous processing of business requests. This data is systematically stored in various persistent data sources. Persistent data sources refer to media capable of storing data long-term and their access interfaces. In a typical software architecture, this might manifest as log files output by the application server, which are stored on a rolling basis by date or size; it could also be specific monitoring or audit tables in a relational database, where each row records the context of a service call; it could be persistent topics in message brokers such as Kafka, which retain business event messages flowing through the system; or it could be the backend storage of distributed tracing systems such as Jaeger or Zipkin, which contains call chain data with detailed tags. Locating these data sources requires determining their specific location and access method based on the environment configuration. For example, this can be done by reading the application configuration file to obtain the database connection string and table name, by querying the API of a log management platform such as the ELK Stack to obtain the log index name, or by obtaining the endpoint address of the tracing system through a service discovery mechanism.

[0039] A unique identifier for a target method is a symbol that clearly refers to a specific method across the entire system. It typically consists of the fully qualified name of the class, the method name, and a list of parameter types. After locating the persistent data source, this identifier is used to construct query conditions or filtering rules to precisely select relevant entries from massive historical records. For example, this might involve executing a SELECT statement in an SQL database with the class name and method name as conditions; using regular expressions for log fields in a log aggregation platform; or consuming and filtering messages with specific header identifiers in a message queue. The resulting record set is a temporary, ordered data container where each record corresponds to a successful or failed call to the target method in history, and includes a snapshot of the context at the time of the call.

[0040] Extracting raw parameter data from each selected record is the process of restoring stored, possibly encoded or serialized, call information into a data structure that the program can process. The specific implementation depends on the data source's storage format: if the record is a JSON-formatted log line, the JSON object needs to be parsed and navigated to the specific field storing the parameter; if the record is a database row, the BLOB or CLOB column of the stored parameter object needs to be read and deserialized; if the record is a binary trace span, the parameter information stored in its tags needs to be decoded. The extracted raw parameter data typically retains its original form at the time of the call and may contain various system-added metadata, debugging information, and raw values ​​that have not been formatted.

[0041] The extracted raw parameter data undergoes format standardization and redundancy cleanup to eliminate inconsistencies arising from diverse data sources and remove information useless for subsequent code generation. Format standardization involves converting data with the same semantics into a standard representation; for example, converting all date and time strings to ISO 8601 format, converting all numerical string representations to their corresponding numeric literals in the programming language, and ensuring that string encoding is uniformly UTF-8. Redundancy cleanup includes deleting system-generated tracking IDs, timestamp metadata, environment variable fields irrelevant to the current test objective, and filtering out optional fields with null or empty string values. After these operations, the raw, messy parameter data is transformed into a standardized set of input parameter data that is cleaner, more consistent in structure and values, and focused on business semantics.

[0042] Serializing normalized input data according to preset key-value pair and hierarchical nesting rules is the process of converting in-memory data structures into a self-describing, portable text representation. The preset rules define how the data is organized. For example, using JSON format requires data to consist of key-value pairs, where values ​​can be nested objects or arrays; or using YAML format emphasizes readability and indentation to represent hierarchy. The serialization process calls corresponding library functions, iterates through the normalized data object, generates keys based on field names, and generates corresponding JSON strings, numbers, booleans, nested objects, or arrays based on the type of field values, ultimately outputting a structured text data string that conforms to the specified syntax.

[0043] Finally, the serialized structured text data is written to a specified file path on the local disk. This involves the operating system's file input / output functions: first, the target directory path is checked and created to ensure its existence; then, a file under that path is opened or created in write mode; the text data string is written to the file as a byte stream; and finally, the file is closed to ensure the data is completely flushed to the disk. After writing is complete, a structured data file is generated in the specified path. This file is independent of the original runtime environment and contains parameter data extracted, cleaned, and formatted from the actual business calls, providing a standardized input carrier for subsequent parsing and code generation steps.

[0044] This embodiment automatically extracts and cleans input parameter data from real business calls from diverse persistent data sources in the runtime environment, and serializes it into a standard structured file. This provides a high-quality, production-realistic input foundation for test code generation, avoiding the subjectivity, bias, and inefficiency of manually constructing test data, and significantly improving the business authenticity and scenario coverage of the test data.

[0045] In one embodiment, step S20 above includes: S201, Establish a file access channel pointing to the structured data file; S202, read the original byte sequence contained in the structured data file in binary mode through the file access channel; S203, decode the original byte sequence into a complete text string according to a preset character encoding rule; S204, Perform whitespace character removal and escape character restoration operations on the complete text string to generate a standardized text data stream; S205, perform lexical scanning on the normalized text data stream to identify and separate structure delimiters, key name strings and value element data, and generate an ordered lexical unit queue; S206, based on the pairing relationship of the structure delimiters in the ordered lexical unit queue, perform recursive descent parsing, construct an intermediate syntax tree containing syntax nodes, and record the parent-child reference relationship between syntax nodes; S207, Traverse the intermediate syntax tree, create a corresponding data node object for each syntax node, and fill the attribute fields of the data node object with the key name string and value element data; S208, based on the parent-child reference relationships between the recorded syntax nodes, links all data node objects hierarchically to form a data node tree.

[0046] In this embodiment, establishing a file access channel to a structured data file is an abstraction mechanism provided by the operating system or runtime environment. It allows a program to access file content stored on persistent media through a logical handle. Establishing this channel typically involves calling a system function, passing in the absolute or relative path of the file in the storage system, and access mode parameters, such as read-only mode. This operation returns a file descriptor or stream object, serving as the entry point for all subsequent read operations. Reading the raw byte sequence of the file in binary mode through this file access channel means that the data is loaded into the program's memory buffer in its most raw, uninterpreted byte stream form. Binary mode ensures that every byte in the file is read as is, avoiding platform-dependent line terminator conversions and other data tampering that might occur in text mode, which is crucial for accurate subsequent decoding. Decoding the read raw byte sequence into a complete text string according to preset character encoding rules is a process of mapping bytes to characters. Preset character encoding rules, such as UTF-8, GBK, or ISO-8859-1, define the correspondence between byte modes and Unicode characters. The decoder iterates through the byte sequence, identifies the characters represented by consecutive bytes according to the encoding rules, and concatenates them into a continuous, complete string object in memory. This string object completely contains all the text content of the file.

[0047] Performing whitespace removal and escape character restoration on this complete text string is a preprocessing step specific to the data format. Whitespace removal removes characters from the text that do not carry syntactic meaning in the data structure definition but are only used to improve human readability, such as spaces, tabs, and newlines. This operation is achieved by scanning the string and filtering out these specific characters. Escape character restoration handles escape sequences used to represent special characters within string literals, such as restoring the sequence \n to a newline character and \" to a double quote character. This process generates a normalized text data stream that removes formatting interference, allowing subsequent lexical analysis to focus on the structural syntax itself.

[0048] Lexical scanning of a normalized text data stream is a process of breaking down a continuous stream of characters into a series of smallest units with independent syntactic meaning. The lexical scanner traverses the text data stream from beginning to end, identifying, according to predefined lexical rules, left curly braces that mark the beginning of a structure, right curly braces that mark the end of a structure, left square brackets that mark the beginning of an array, right square brackets that mark the end of an array, colons that separate key-value pairs, commas that separate array elements, and key strings enclosed in quotation marks, numeric literals, boolean literals, and null values. Each identified unit is encapsulated as a lexical unit object, which typically contains the unit type and its value in the original text. These lexical units are added to a queue in the order they were identified, forming an ordered lexical unit queue that linearly reflects the syntactic structure sequence of the original text.

[0049] Based on the pairing relationships of structure delimiters in this ordered queue of lexical units, recursive descent parsing is performed. Recursive descent is a top-down parsing method that simulates grammatical production rules through a set of mutually recursive functions. The parser starts processing from the head of the queue, calling the corresponding parsing function (e.g., parsing an object) based on the type of lexical unit encountered (e.g., a left curly brace). Inside this function, it continuously consumes units in the queue, expecting and matching specific unit sequences according to grammatical rules, such as expecting a key string followed by a colon and then a value within an object. When encountering nested structures (e.g., a value that is itself an object or array), the function recursively calls itself or other parsing functions. During this recursive matching and consumption process, the parser simultaneously constructs an intermediate syntax tree. Each grammatical node in the tree corresponds to a grammatical structure, such as an object node, an array node, a key-value pair node, or a value node. The parsing process precisely records the parent-child reference relationships between these grammatical nodes; for example, an object node contains multiple key-value pair child nodes, and an array node contains multiple value child nodes. This intermediate syntax tree fully captures the abstract syntactic structure of the original data text, but does not directly contain the specific key-name and value data.

[0050] The intermediate syntax tree is traversed, creating a corresponding data node object for each syntax node in the tree. A data node object is an internal data structure used by the program to represent data entities; it typically contains attribute fields to store the node's type, name, and value. For syntax nodes with corresponding key-value pairs, their key name string (obtained from the lexical unit) is extracted and assigned to the data node object's name attribute; their value syntax nodes (which may be basic values, objects, or arrays) are further processed: if it's a basic value, the value data is extracted from the corresponding lexical unit and populated; if it's an object or array, child data node objects are created for it. This process is performed recursively, ensuring that each syntax structure is converted into a data node object populated with specific data.

[0051] Finally, based on the parent-child reference relationships between syntax nodes recorded during the syntax parsing phase, all created data node objects are hierarchically linked. Specifically, for each pair of syntax nodes with a parent-child relationship, their corresponding data node objects are found, and the same reference relationship is established between the data node objects. For example, an object data node is set as the parent node of all its internal key-value pair data nodes, and an array data node is set as the parent node of all its element data nodes. Through this systematic linking operation, all discrete data node objects are organized into a tree network with a clear hierarchical structure, namely the data node tree. This tree completely reproduces the logical hierarchy and data content contained in the original structured data file in memory through object references.

[0052] This embodiment automates and pipelines a series of complex processes, including reading, decoding, normalizing, lexical analysis, syntax parsing, and data structure construction of structured data files. It accurately converts externally stored formatted text into a tree-like data structure in memory that can be directly traversed and manipulated programmatically. This process avoids the inherent misunderstandings, programming errors, and inefficiencies of manually interpreting complex data formats and writing parsing code, ensuring high fidelity, high efficiency, and high reliability in the conversion from persistent storage to in-memory computing.

[0053] In one embodiment, step S30 above includes: S301, Receive the classpath identifier of the target parameter model; S302, based on the classpath identifier, the corresponding class is loaded into memory through a dynamic structure acquisition mechanism; S303, obtain the member field definitions of the loaded class through the dynamic structure acquisition mechanism, and generate a set of field names, a set of field types, and a set of field modifiers; S304, Obtain the constructor definitions of the loaded classes through the dynamic structure acquisition mechanism, and generate a constructor set; S305, Obtain the access method definitions of the loaded classes through the dynamic structure acquisition mechanism, and generate an access method set; S306, merge the set of field names, the set of field types, the set of field modifiers, the set of constructors, and the set of access methods to generate class structure information.

[0054] In this embodiment, receiving the classpath identifier of the target parameter model is the initialization input step of this process. The classpath identifier is a string sequence conforming to the specifications of a specific programming language and runtime environment, uniquely identifying the location of the target class in the class loading space. In a Java Virtual Machine (JVM) based environment, this is typically represented by a fully qualified class name, such as com.example.domain.FinancialTransaction; in the .NET environment, it is the fully qualified type name including the assembly name. This identifier can be passed to the system through various means, such as reading configuration files, parsing command-line arguments, or calling application programming interfaces (APIs). Upon receipt, the system verifies it to ensure that its format is valid and theoretically reachable in the current runtime context.

[0055] Based on the verified classpath identifier, the corresponding class is loaded into memory through a dynamic structure acquisition mechanism. The core of this mechanism is runtime type information lookup capabilities, which are manifested as a reflection system in many statically typed languages. This process does not directly instantiate the class; instead, it triggers the class loader subsystem. The system first passes the classpath identifier to the current thread's context class loader, which searches its responsible classpath, module path, or dependency artifact set to locate the binary resource storing the class definition. Subsequently, the class loader executes the standard loading, linking, and initialization process: reading the class's bytecode, verifying its format, resolving its symbolic references, recursively loading its superclasses and other referenced classes if necessary, and finally creating an internal representation of the class in the JVM's method area or the .NET application domain. After successful loading, the reflection API provides an entry point, typically a Class object (Java) or a Type object (C#), which serves as a handle for all subsequent metadata lookup operations, representing the loaded and introspective class definition.

[0056] The system retrieves the member field definitions of loaded classes using a dynamic structure retrieval mechanism. A specific method of the reflection handle is called, such as `getDeclaredFields()` in Java. This method returns an array containing all fields declared in the class, including private, protected, and public fields. This array is iterated through, and further queries are performed on each field object: `getName()` is called to extract the field's name string and add it to the field name collection; `getType()` is called to obtain the Class object representing the field's data type and add this type information to the field type collection; `getModifiers()` is called to obtain an integer bitmask, which is then decoded using bitwise operations or utility classes to determine if the field is public, private, protected, static, final, etc., and the parsed modifier information is added to the field modifier collection. This step precisely captures all the declaration characteristics of each data member that constitutes the object's state.

[0057] The constructor definitions of loaded classes are obtained through the same dynamic structure acquisition mechanism. The system calls the `getDeclaredConstructors()` method of the reflection handle. This method returns all constructors declared in the class. Traversing the returned array, for each constructor object, its parameter type list, modifiers, and possible declared exceptions can be extracted. This information is encapsulated and added to the constructor collection. This collection fully describes all possible ways to instantiate this type of object, including default constructors and parameterized constructors.

[0058] The access method definitions of loaded classes are obtained through a dynamic structure retrieval mechanism. Access methods typically refer to methods that read and write field values, following naming conventions. The system calls `getDeclaredMethods()` to retrieve all methods, which are then filtered and identified using a set of rules. For example, in Java Bean conventions, methods starting with `get` or `is` and without parameters are identified as getters, while methods starting with `set` and with one parameter are identified as setters. The method array is traversed, and this rule is applied to extract the matching method signature information (including method name, return type, parameter types, and modifiers) and add it to the access method set. This set reflects the field access interfaces exposed as methods.

[0059] Finally, the field name set, field type set, field modifier set, constructor set, and access method set generated in the above steps are merged to generate class structure information. This merging is not a simple data accumulation, but a structured encapsulation process. The system creates a new data structure, such as a container object containing multiple internal lists or mappings. Each set is placed into this container in an orderly manner, establishing relationships between them. For example, the i-th element in the field name set corresponds to the i-th element in the field type set in terms of type, and its modifier corresponds to the i-th element in the field modifier set in terms of modifier. The constructor and access method sets are appended as separate lists. The final output class structure information is a complete and self-consistent meta-data package that provides a precise runtime blueprint of the target class from the three dimensions of fields, constructors, and access methods.

[0060] This embodiment automatically loads the class by receiving the class identifier and using reflection to systematically extract the declarations of all its fields, constructors, and access methods. These are then integrated into structured class structure information, providing a precise and complete type system blueprint for subsequent data-to-code mapping. This process completely replaces the manual method of consulting documentation or source code to understand the class structure and making notes. It ensures that the generated initialization code maintains strict consistency with the target model in terms of field matching, type safety, and access methods, eliminating errors such as attribute omissions and type conversion anomalies caused by human negligence or misunderstanding. This fundamentally guarantees the semantic correctness of the automatically generated code.

[0061] In one embodiment, step S40 above includes: S401, recursively traverse the data node tree according to the class structure information to access the current node, and match the field type corresponding to the current node in the class structure information; S402, in response to the field type being a basic type, extract the value data of the current node and generate a field assignment statement; S403, in response to the field type being an object type, enter the child nodes of the current node to perform a depth traversal operation and generate nested code snippets; S404, In response to the field type being a collection type, extract the array elements of the current node and generate collection initialization and element addition statements; S405, the field assignment statement, nested code snippet and / or collection initialization and element addition statement are recorded as initialization code snippets.

[0062] In this embodiment, the data node tree is recursively traversed based on the class structure information to access the current node, and the field type corresponding to the current node is matched in the class structure information. Recursive traversal is a depth-first algorithm execution mode. It starts from the root node of the data node tree, systematically explores each branch until a leaf node, and then backtracks to explore unvisited branches. In each recursive call, the currently accessed data node becomes the focus of processing. This node carries a key identifier that matches the name of a field defined in the class structure information. The matching process is completed by querying the set of field names stored in the class structure information. Once a field entry with a matching name is found, its associated field type definition is obtained. This matching operation establishes a semantic correspondence between data nodes and class structure fields, ensuring that subsequent code generation strictly follows the constraints of the type system.

[0063] In response to a field type belonging to a basic type, the system extracts the value data of the current node and generates a field assignment statement. Basic types refer to types built into the programming language that represent simple values, such as integers, floating-point numbers, booleans, characters, and strings. When a matched field type is determined to be a basic type, the system reads its stored value data from the current data node. This value data is typically represented as a string in the data node tree and needs to be converted to the corresponding literal form according to the syntax rules of the target programming language. For example, for integer types, it must be ensured that the string can be parsed as an integer without unnecessary formatting; for string types, quotation marks must be added around the value and internal escape characters must be handled. Subsequently, the system constructs the assignment statement according to the syntax template, generating a line of code like `fieldName = valueLiteral;`. This statement fulfills the programming intent of assigning a constant value to a specific field.

[0064] In response to a field type being an object, a depth-first traversal is performed on the child nodes of the current node, generating nested code snippets. The object type indicates that the field's value is another complex data structure defined by a class. When a field type is matched as an object, the system needs to generate complete initialization code for this nested object. At this point, the recursive traversal process delves into the set of child nodes of the current node, which collectively describe the values ​​of the fields within the nested object. The system needs to obtain or reference the class structure information corresponding to the nested object, which can be achieved by dynamically loading its class and extracting metadata, or by retrieving it from a pre-loaded metadata cache. Using this nested class structure information as a blueprint, the same traversal, matching, and code generation process is recursively initiated on the child node tree. This recursive call will produce a self-contained code block for initializing the nested object. This code block may contain multiple statements and is encapsulated as an independent logical unit, forming a nested code snippet.

[0065] In response to a field type being a collection type, the array elements of the current node are extracted, and collection initialization and element addition statements are generated. A collection type refers to a container type used to hold multiple elements, such as a list, set, or map. When a field type is matched as a collection type, the processing is divided into two parts. First, a collection instantiation statement is generated, which is the code that creates a container of a specific collection type, such as a List. <elementtype>`list = new ArrayList<>();` This statement specifies the generic type of the collection and calls the constructor. Then, the system iterates through the child nodes representing the collection elements under the current data node. For each child node, the corresponding element value expression is recursively generated based on its data type. If the element is a primitive type, its value literal is generated; if the element is an object type, nested object initialization blocks are recursively generated; if the element itself is a collection, this processing logic is applied again. For each generated element value expression, the system constructs a statement to add it to the collection container, such as `list.add(elementValue);`. For mapped types, expressions for both the key and value, along with the addition statement, need to be generated separately.

[0066] Field assignment statements, nested code snippets, and / or collection initialization and element addition statements are recorded as initialization code snippets. During traversal, the code units generated for each node are discrete. The system needs a mechanism to collect and temporarily store these units. Recording operations are typically implemented by adding the generated statements to a list or buffer associated with the current recursive context. Since the traversal is recursive, each recursive level may maintain its own set of snippets. For object type fields, the generated nested code snippets are recorded as a whole; for collection types, the initialization statements and a series of addition statements are recorded as a logical group. Ultimately, all recorded snippets constitute a hierarchical set of code snippets that preserve the structural information of the data node tree, providing raw materials for subsequent assembly steps.

[0067] This embodiment achieves automated conversion from hierarchical data of arbitrary complexity to type-safe, structurally complete, and semantically correct object construction code by recursively traversing the data node tree guided by class structure information and dynamically generating precisely matching initialization code snippets based on field types. This systematically solves the code generation challenges in mixed scenarios such as basic type assignment, deep object nesting, and collection container initialization, completely replacing the tedious, error-prone, and inefficient labor that inevitably accompanies manually writing such code. It ensures a high degree of consistency between the generated code and the target model, thus providing a reliable guarantee for building high-coverage and high-reliability automated tests.

[0068] In one embodiment, step S60 above includes: S601, Load a preset syntax matching template, and perform a scanning and comparison operation on the object initialization statement block according to the syntax matching template, extract character fragments that satisfy the syntax matching template from the object initialization statement block, and collect the character fragments into a full class identifier text; S602, construct a unique storage container with deduplication function, and fill the text elements contained in the full class identifier text into the unique storage container to filter duplicate items; S603, extract all elements retained in the unique storage container as a set of non-repeating class identifiers; S604, determine the corresponding package path based on the set of non-repeating class identifiers, and generate dependency class information.

[0069] In this embodiment, loading a pre-defined syntax matching template is a fundamental preparatory step for initiating the scanning analysis. A syntax matching template is a set of predefined rules that formally describe specific syntactic patterns in the appearance and reference of class identifiers in the source code text of the target programming language. These patterns typically exist in the form of regular expressions, finite state automata, or more complex pattern matching rules. For example, one template might define a pattern to capture a sequence of identifiers and left parentheses following the `new` keyword; another template might define a pattern to capture identifiers within parentheses in type casting expressions; and yet another template might define a pattern to capture identifiers before a dot in static method calls. The loading process instantiates this set of rules into memory from a configuration file, embedded resources, or database, forming an executable pattern set that provides a basis for subsequent text analysis.

[0070] The object initialization statement block is scanned and compared according to the loaded syntax matching templates. The object initialization statement block is a string containing complete object construction logic. The scan and comparison operation takes this string as input and, starting from the beginning, applies all loaded syntax matching templates for parallel or sequential matching attempts. This is similar to a multi-pattern string matching process. A hit is triggered whenever the scan position moves to a character sequence that satisfies the pattern defined by any template. Extracting character segments from the object initialization statement block that satisfy the syntax matching template means that after a successful pattern match, the substring corresponding to the key part of the pattern is extracted from the original text. For example, for the pattern matching `new Transaction()`, the extraction operation will precisely extract the substring `Transaction`, ignoring `new`, spaces, and parentheses. For more complex patterns such as generic `List`... <string>The truncation operation may extract both a List and a String. All successfully extracted character fragments are added to a temporary list or collection; this collection, which gathers all matching results, is the full class identifier text. It contains all explicit class references within the code block, but may contain a large number of duplicates.

[0071] Building a unique storage container with deduplication capabilities is a data structure preparation for deduplication operations. In computer science, a set is a data structure that does not allow duplicate elements. Hash sets are an efficient implementation of this data structure. Based on hash tables, they quickly locate and compare elements by calculating their hash codes, thus ensuring the uniqueness of elements within the container. Building such a container involves initializing an empty hash set instance in memory.

[0072] The text elements contained in the full set of class identifier texts are populated into this unique storage container to filter duplicates. This is an iterative process. The system iterates through each text element (i.e., each extracted class name string) in the full set of class identifier texts and attempts to add it to the hash set. The internal mechanism of the hash set's addition operation checks whether the element already exists: by calculating its hash code and searching in the hash table, if a duplicate element is found, the addition is rejected; otherwise, the insertion is performed. Through this iterative addition process, all duplicate class names are automatically filtered out, and only the first occurrence of each unique class name is retained in the container's internal data structure.

[0073] Extract all elements remaining in the unique storage container as a set of non-repeating class identifiers. After the filling and filtering operations are complete, the hash set contains all unique class identifiers. An enumeration of all these unique elements can be obtained by calling the container's iterator or converting it to a list. This enumeration result is encapsulated into a new ordered or unordered set, namely the set of non-repeating class identifiers. This set is the exact output of the deduplication operation, representing the unique class set upon which the object initialization block depends.

[0074] The system determines the corresponding package path based on a set of unique class identifiers and generates dependency class information. A class identifier is usually just a simple name, but to correctly reference it in the source code, its complete package path (namespace) is needed. Determining the package path is a mapping or lookup process. This can be implemented by: using Java reflection to attempt to load the class using the current thread's context class loader; if successful, retrieving the package name from the obtained Class object; maintaining a project- or system-level classpath index or mapping table and retrieving the package name; or parsing the project's build descriptor file to deduce the class-package relationship. The system iterates through each class name in the set of unique class identifiers, executing the package path determination logic described above, and associating each class name with a complete package reference path (e.g., java.util.List). Finally, all class name-package path pairs are organized into a structured data format, such as a list, a mapping, or a custom data object; this structured data is the dependency class information. It fully describes the external type dependencies of the generated code.

[0075] This embodiment generates structured dependency class information by automatically scanning the generated code text, accurately extracting all class references, efficiently removing duplicates, and parsing to obtain complete package path information. This process ensures the accuracy and completeness of the subsequently generated import statements, eliminating the risks of omissions, duplications, and path errors that inevitably occur when manually checking code and writing import statements. It guarantees the independent compilability and project integration of the automatically generated code, achieving a closed-loop automation from data to immediately usable test code.

[0076] In one embodiment, step S70 above includes: S701, parse the dependency class information, traverse the class identifiers contained in the dependency class information and determine the package reference path corresponding to each class identifier; S702, according to the syntax rules of the target programming language, constructs a single-line import statement for each package reference path; S703 performs a lexicographical sorting operation on all single-line import statements, arranges the sorted single-line import statements with line breaks and format alignment, and generates a dependency import statement block; S704, the dependency import statement block and the object initialization statement block are assembled according to a preset top-bottom positional relationship to form the final code text; S705, output the final code text to the target output channel.

[0077] In this embodiment, resolving dependency class information is the initial operation for processing structured metadata. Dependency class information typically exists in the form of a key-value map, a list, or a custom data structure, where each entry associates a class identifier with its complete package reference path. The resolution process involves reading the internal representation of this data structure and traversing all the entries stored within it. For each entry, the system extracts the class identifier and simultaneously obtains or confirms its corresponding package reference path. In implementation, if the package path is already directly stored in the dependency class information, it is read directly; if only the class identifier is stored, it may be necessary to supplement the determination of its complete package path by querying the class loader, searching the class path index, or accessing a pre-built mapping table. This step ensures that subsequent processing is based on the unique and accurate fully qualified name of each class.

[0078] Following the syntax rules of the target programming language, a single-line import statement is constructed for each package reference path. Programming languages ​​typically have strict syntax rules for declaring references to classes in another package. For example, in Java, the rule requires the use of the `import` keyword, followed by the complete package path and class name, ending with a semicolon. The system applies this rule template to each identified package reference path. The construction process is essentially string concatenation: connecting language-specific keywords, dot separators in the package path, class identifiers, and necessary punctuation marks in the correct order. For variations such as static imports or wildcard imports, the syntax template is adjusted accordingly. Each package reference path is transformed into a single, complete, and syntactically correct line of source code through this operation.

[0079] All single-line import statements are sorted lexicographically. Sorting is a crucial step in code standardization and readability improvement. Lexicographical sorting arranges the statement set according to the character encoding order of the strings. In implementation, the system places all generated single-line import statements into a sortable container, such as a list, and then calls a sorting algorithm, such as quicksort or mergesort. Sorting comparisons are based on the entire statement string, naturally ensuring that statements belonging to the same package path prefix are arranged adjacently. The sorting operation ensures the determinism and consistency of the generated code blocks, avoiding output fluctuations caused by uncertain processing order.

[0080] The sorted single-line import statements are then arranged with line breaks and formatted to generate a dependency import block. The sorted list of statements is discrete and needs to be combined into a coherent block of text. Line breaks mean inserting a newline character after each statement, ensuring each statement occupies a separate line. Formatting typically involves adding consistent indentation at the beginning of each line, such as a certain number of spaces or a tab, visually aligning the entire code block to a common starting column. Some coding standards also require inserting blank lines between specific groups of statements for logical separation. This formatting process transforms the sorted list into a coherent, human-readable paragraph of text that conforms to a common coding style—the dependency import block.

[0081] The dependency import block and object initialization block are assembled according to a predefined top-down order to form the final code text. This predefined top-down order follows the typical organization of source code files: import declarations at the top, followed by the main code logic. The assembly process is a string concatenation operation. First, the complete text of the dependency import block is placed, then one or two newline characters are added as block separators, followed by the complete text of the object initialization block. In some implementations, comments or blank lines may be inserted between the two blocks to enhance readability. The assembly process ensures that the two logical blocks maintain the correct relative order and spacing in the final output text, forming a syntactically complete and clearly structured compilable code unit.

[0082] The final code text is output to the target output channel. The target output channel defines the endpoint for delivering the generated code. This can be a file system path, where the system writes the text content to disk with a specified character encoding by creating or overwriting files. It can also be a standard output stream, printing the text to the console for user viewing or redirecting it. In an integrated development environment or web service context, the output channel might be a text editor component in a graphical user interface or an HTTP response body. The output operation needs to handle possible exceptions, such as insufficient file permissions or insufficient disk space, and ensure that the data is completely flushed to the target media. After output is complete, the generated code is in a position where it can be directly used by the compiler or interpreter.

[0083] This embodiment parses dependency information, generates syntactically correct import statements, sorts and formats them, assembles them into well-structured code blocks, and merges them with the main code logic for output. This ensures that the automatically generated test code has complete compilability and direct project integration capabilities. This process eliminates the tediousness and errors of manually writing and managing import statements, guarantees the industrial-grade quality and reliability of the generated code, and achieves end-to-end automated generation from raw business data to high-quality test code that can be used immediately without manual intervention.

[0084] In one embodiment, an object instantiation code generation apparatus is provided, which corresponds one-to-one with the object instantiation code generation method in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the object instantiation code generation device of the present invention. The modules include: input parameter acquisition and disk storage module 10, structured parsing and tree construction module 20, class structure extraction module 30, code snippet generation module 40, statement block assembly module 50, dependency class information generation module 60, and dependency import and output module 70. Detailed descriptions of each functional module are as follows: The input parameter acquisition and disk storage module 10 is used to acquire input parameter data generated by the operating environment and save the input parameter data as a structured data file; The structured parsing and tree building module 20 is used to read the structured data file and parse the structured data file to build a data node tree; The class structure extraction module 30 is used to obtain the target parameter model and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism. The code snippet generation module 40 is used to recursively traverse the data node tree based on the class structure information and generate corresponding initialization code snippets according to the field type; The statement block assembly module 50 is used to assemble the initialization code fragments to generate object initialization statement blocks; The dependency class information generation module 60 is used to scan the object initialization statement block to extract the full class identifier text, and perform a deduplication operation on the full class identifier text to generate dependency class information; The dependency import output module 70 is used to generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0085] In one embodiment, the input parameter acquisition and disk loading module 10 is specifically used for: Locate the persistent data source that stores method call records in the runtime environment; Based on the unique identifier of the target method, a set of records containing the target method call information is filtered out from the persistent data source; Extract the original parameter data corresponding to each call from the record set; Perform format unification and redundancy cleanup operations on the original parameter data to generate standardized input parameter data; The standardized input parameter data is serialized into structured text data according to preset key-value pair and hierarchical nesting rules; The structured text data is written to a specified file path on the local disk to generate a structured data file.

[0086] In one embodiment, the structured parsing and tree-building module 20 is specifically used for: Establish a file access channel pointing to the structured data file; The raw byte sequence contained in the structured data file is read in binary mode through the file access channel; The original byte sequence is decoded into a complete text string according to a preset character encoding rule; Perform whitespace removal and escape character restoration operations on the complete text string to generate a standardized text data stream; Lexical scanning is performed on the normalized text data stream to identify and separate structure delimiters, key name strings, and value element data, generating an ordered lexical unit queue. Based on the pairing relationship of the structure delimiters in the ordered lexical unit queue, recursive descent parsing is performed to construct an intermediate syntax tree containing syntax nodes and record the parent-child reference relationship between syntax nodes; Traverse the intermediate syntax tree, create a corresponding data node object for each syntax node, and populate the attribute fields of the data node object with the key name string and value element data; Based on the parent-child reference relationships between the recorded syntax nodes, all data node objects are hierarchically linked to form a data node tree.

[0087] In one embodiment, the class structure extraction module 30 is specifically used for: Receives the classpath identifier of the target parameter model; Based on the classpath identifier, the corresponding class is loaded into memory through a dynamic structure acquisition mechanism; The dynamic structure acquisition mechanism is used to obtain the member field definitions of the loaded classes and generate a set of field names, a set of field types, and a set of field modifiers. The constructor definitions of loaded classes are obtained through the dynamic structure acquisition mechanism, and a set of constructors is generated. The access method definitions of loaded classes are obtained through the dynamic structure acquisition mechanism, and an access method set is generated. The set of field names, the set of field types, the set of field modifiers, the set of constructors, and the set of access methods are merged to generate class structure information.

[0088] In one embodiment, the code snippet generation module 40 is specifically used for: Based on the class structure information, the data node tree is recursively traversed to access the current node, and the field type corresponding to the current node is matched in the class structure information. In response to the fact that the field type is a basic type, the value data of the current node is extracted and a field assignment statement is generated; In response to the fact that the field type is an object type, a depth-first traversal operation is performed on the child nodes of the current node, and nested code snippets are generated; In response to the fact that the field type is a collection type, extract the array elements of the current node and generate collection initialization and element addition statements; Record the field assignment statements, nested code snippets, and / or collection initialization and element addition statements as initialization code snippets.

[0089] In one embodiment, the dependency class information generation module 60 is specifically used for: Load a preset syntax matching template, and perform a scanning and comparison operation on the object initialization statement block according to the syntax matching template. Extract character fragments that satisfy the syntax matching template from the object initialization statement block, and collect the character fragments into a full class identifier text. Construct a unique storage container with deduplication function, and fill the unique storage container with the text elements contained in the full class identifier text to filter duplicate items; Extract all elements retained in the unique storage container as a set of non-repeating class identifiers; The corresponding package path is determined based on the set of non-repeating class identifiers, and dependency class information is generated.

[0090] In one embodiment, the dependency import output module 70 is specifically used for: The dependency class information is parsed, the class identifiers contained in the dependency class information are traversed, and the package reference path corresponding to each class identifier is determined; Based on the syntax rules of the target programming language, construct a single-line import statement for each package reference path; Perform a lexicographical sorting operation on all single-line import statements, then arrange the sorted single-line import statements with line breaks and format alignment to generate a dependency import statement block; The dependency import statement block and the object initialization statement block are assembled according to a preset top-bottom order to form the final code text; The final code text is output to the target output channel.

[0091] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements a server-side function or step of an object instantiation code generation method.

[0092] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of an object instantiation code generation method.

[0093] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the input parameter data generated by the operating environment and save the input parameter data as a structured data file; Read the structured data file and parse the structured data file to construct a data node tree; Obtain the target parameter model, and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism; Based on the class structure information, the data node tree is recursively traversed, and corresponding initialization code snippets are generated according to the field type; The initialization code fragments are assembled to generate an object initialization statement block; Scan the object initialization statement block to extract all class identifier text, and perform deduplication on the all class identifier text to generate dependency class information; Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0094] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Obtain the input parameter data generated by the operating environment and save the input parameter data as a structured data file; Read the structured data file and parse the structured data file to construct a data node tree; Obtain the target parameter model, and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism; Based on the class structure information, the data node tree is recursively traversed, and corresponding initialization code snippets are generated according to the field type; The initialization code fragments are assembled to generate an object initialization statement block; Scan the object initialization statement block to extract all class identifier text, and perform deduplication on the all class identifier text to generate dependency class information; Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

[0095] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0096] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0098] It should be noted that any software tools or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0099] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.< / string> < / elementtype> < / string>

Claims

1. A method for generating object instantiation code, characterized in that, Includes the following steps: Obtain the input parameter data generated by the operating environment and save the input parameter data as a structured data file; Read the structured data file and parse the structured data file to construct a data node tree; Obtain the target parameter model, and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism; Based on the class structure information, the data node tree is recursively traversed, and corresponding initialization code snippets are generated according to the field type; The initialization code fragments are assembled to generate an object initialization statement block; Scan the object initialization statement block to extract all class identifier text, and perform deduplication on the all class identifier text to generate dependency class information; Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

2. The object instantiation code generation method as described in claim 1, characterized in that, Acquire the input parameter data generated by the runtime environment and save the input parameter data as a structured data file, including: Locate the persistent data source that stores method call records in the runtime environment; Based on the unique identifier of the target method, a set of records containing the target method call information is filtered out from the persistent data source; Extract the original parameter data corresponding to each call from the record set; Perform format unification and redundancy cleanup operations on the original parameter data to generate standardized input parameter data; The standardized input parameter data is serialized into structured text data according to preset key-value pair and hierarchical nesting rules; The structured text data is written to a specified file path on the local disk to generate a structured data file.

3. The object instantiation code generation method as described in claim 1, characterized in that, Reading the structured data file and parsing it to construct a data node tree includes: Establish a file access channel pointing to the structured data file; The raw byte sequence contained in the structured data file is read in binary mode through the file access channel; The original byte sequence is decoded into a complete text string according to a preset character encoding rule; Perform whitespace removal and escape character restoration operations on the complete text string to generate a standardized text data stream; Lexical scanning is performed on the normalized text data stream to identify and separate structure delimiters, key name strings, and value element data, generating an ordered lexical unit queue. Based on the pairing relationship of the structure delimiters in the ordered lexical unit queue, recursive descent parsing is performed to construct an intermediate syntax tree containing syntax nodes and record the parent-child reference relationship between syntax nodes; Traverse the intermediate syntax tree, create a corresponding data node object for each syntax node, and populate the attribute fields of the data node object with the key name string and value element data; Based on the parent-child reference relationships between the recorded syntax nodes, all data node objects are hierarchically linked to form a data node tree.

4. The object instantiation code generation method as described in claim 1, characterized in that, Obtain the target parameter model, and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism, including: Receives the classpath identifier of the target parameter model; Based on the classpath identifier, the corresponding class is loaded into memory through a dynamic structure acquisition mechanism; The dynamic structure acquisition mechanism is used to obtain the member field definitions of the loaded classes and generate a set of field names, a set of field types, and a set of field modifiers. The constructor definitions of loaded classes are obtained through the dynamic structure acquisition mechanism, and a set of constructors is generated. The access method definitions of loaded classes are obtained through the dynamic structure acquisition mechanism, and an access method set is generated. The set of field names, the set of field types, the set of field modifiers, the set of constructors, and the set of access methods are merged to generate class structure information.

5. The object instantiation code generation method as described in claim 1, characterized in that, Based on the class structure information, the data node tree is recursively traversed, and corresponding initialization code snippets are generated according to the field types, including: Based on the class structure information, the data node tree is recursively traversed to access the current node, and the field type corresponding to the current node is matched in the class structure information. In response to the fact that the field type is a basic type, the value data of the current node is extracted and a field assignment statement is generated; In response to the fact that the field type is an object type, a depth-first traversal operation is performed on the child nodes of the current node, and nested code snippets are generated; In response to the fact that the field type is a collection type, extract the array elements of the current node and generate collection initialization and element addition statements; Record the field assignment statements, nested code snippets, and / or collection initialization and element addition statements as initialization code snippets.

6. The object instantiation code generation method as described in claim 1, characterized in that, The object initialization statement block is scanned to extract all class identifier text, and deduplication is performed on the all class identifier text to generate dependency class information, including: Load a preset syntax matching template, and perform a scanning and comparison operation on the object initialization statement block according to the syntax matching template. Extract character fragments that satisfy the syntax matching template from the object initialization statement block, and collect the character fragments into a full class identifier text. Construct a unique storage container with deduplication function, and fill the unique storage container with the text elements contained in the full class identifier text to filter duplicate items; Extract all elements retained in the unique storage container as a set of non-repeating class identifiers; The corresponding package path is determined based on the set of non-repeating class identifiers, and dependency class information is generated.

7. The object instantiation code generation method as described in claim 1, characterized in that, Generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block, including: The dependency class information is parsed, the class identifiers contained in the dependency class information are traversed, and the package reference path corresponding to each class identifier is determined; Based on the syntax rules of the target programming language, construct a single-line import statement for each package reference path; Perform a lexicographical sorting operation on all single-line import statements, then arrange the sorted single-line import statements with line breaks and format alignment to generate a dependency import statement block; The dependency import statement block and the object initialization statement block are assembled according to a preset top-bottom order to form the final code text; The final code text is output to the target output channel.

8. An object instantiation code generation apparatus, characterized in that, The object instantiation code generation device includes: The input parameter acquisition and disk storage module is used to acquire input parameter data generated by the operating environment and save the input parameter data as a structured data file; The structured data parsing and tree building module is used to read the structured data file and parse the structured data file to build a data node tree; The class structure extraction module is used to obtain the target parameter model and extract the class structure information contained in the target parameter model through a dynamic structure acquisition mechanism. The code snippet generation module is used to recursively traverse the data node tree based on the class structure information and generate corresponding initialization code snippets according to the field type; The statement block assembly module is used to assemble the initialization code fragments to generate object initialization statement blocks; The dependency class information generation module is used to scan the object initialization statement block to extract all class identifier text, and perform deduplication operation on the all class identifier text to generate dependency class information; The dependency import output module is used to generate a dependency import statement block based on the dependency class information, and output the dependency import statement block and the object initialization statement block.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an object instantiation code generation program stored in the memory and executable on the processor, wherein when the object instantiation code generation program is executed by the processor, it implements the steps of the object instantiation code generation method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an object instantiation code generation program, which, when executed by a processor, implements the steps of the object instantiation code generation method as described in any one of claims 1-7.

Images