CN109308260B - Method and terminal for automatically generating unit test code - Google Patents
Method and terminal for automatically generating unit test code Download PDFInfo
- Publication number
- CN109308260B CN109308260B CN201811004196.6A CN201811004196A CN109308260B CN 109308260 B CN109308260 B CN 109308260B CN 201811004196 A CN201811004196 A CN 201811004196A CN 109308260 B CN109308260 B CN 109308260B
- Authority
- CN
- China
- Prior art keywords
- input
- piling
- class
- output
- unit test
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method and a terminal for automatically generating unit test codes, which can automatically generate the unit test codes by receiving the appointed input and output aiming at a unit to be tested, analyzing the input and output to obtain all possible branches, analyzing the input and output of each branch, judging whether piling is needed or not, if so, piling is needed, and generating the unit test codes based on all the branches, thereby reducing the complicated and repeated work, being also used in the later maintenance, saving the time and improving the work efficiency.
Description
Technical Field
The invention relates to the technical field of software testing, in particular to a method and a terminal for automatically generating unit testing codes.
Background
Unit testing is where a developer writes a small piece of code to check that a small, well-defined function of the code under test is correct. Generally, a unit test is used to determine the behavior of a particular function under a particular condition or scenario. Unit testing is the most basic and important means for the function and robustness of code and is a very important link in the whole software engineering.
However, writing unit test is tedious and time-consuming, if a method has a judgment statement consisting of 3 conditions, then to achieve its complete branch coverage (so-called branch coverage, which means that the code of unit test runs through all branches), the developer needs to write 23The more branches of a program, the more test cases written to realize branch coverage, the more test cases will increase exponentially, since most of the codes are the same and only the input parameters are different, the test cases will be different from each other greatly and have no technical content, the codes for unit test are not simple, and the codes for unit test will follow the change of the software codesIt takes more time to update, i.e., to continually maintain, the unit test code.
In addition to the time cost, unit testing requires a learning cost, and a tester needs to perform system learning to skillfully master the skills of writing unit test codes. The tester specifies certain conditions under which a certain method or function is expected to obtain a specific result, and one method or function may depend on other method functions, but the system only runs the tested code block during the unit test, and any other method or function is not executed, so that the tester needs to simulate the dependent methods or functions and make the dependent methods or functions return to the specified value without being executed, and the behavior, called pile driving (mock), in the unit test can not drive the pile, and whether the pile driving is correct determines the effect of the unit test.
In summary, unit testing is very important, but under the traditional unit testing framework, programmers are reluctant to write, unit testing requires testers to learn a third-party testing framework, write a large number of repeated codes and continuously maintain, and the testers need to master the piling technology, which is time-consuming and labor-consuming.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: the method and the terminal for automatically generating the unit test codes can realize automatic generation of the unit test codes, reduce complicated and repeated work, save time and improve efficiency.
In order to solve the technical problems, the invention adopts a technical scheme that:
a method of automatically generating unit test code, comprising the steps of:
s1, receiving the specified input and output aiming at the unit to be tested;
s2, analyzing the input and output to obtain all possible branches;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
s4, generating unit test codes based on all branches.
In order to solve the technical problem, the invention adopts another technical scheme as follows:
a terminal for automatically generating unit test code, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:
s1, receiving the specified input and output aiming at the unit to be tested;
s2, analyzing the input and output to obtain all possible branches;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
s4, generating unit test codes based on all branches.
The invention has the beneficial effects that: through receiving the input and output appointed to the unit that awaits measuring, analysis input and output obtain all branches that probably exist, the input and output of each branch is reexamined, judges whether need pile, if need then pile, and based on all branches, the generation unit test code can realize automatic generation unit test code, reduces loaded down with trivial details repeated work, also can use in the maintenance in later stage, save time has improved work efficiency.
Drawings
FIG. 1 is a flow chart of a method for automatically generating unit test code in accordance with an embodiment of the present invention;
FIG. 2 is a schematic structural diagram of a terminal for automatically generating unit test codes according to an embodiment of the present invention;
description of reference numerals:
1. a terminal for automatically generating a unit test code; 2. a memory; 3. a processor.
Detailed Description
In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.
The most key concept of the invention is that all possible branches are obtained by receiving the specified input and output aiming at the unit to be tested and analyzing the input and output; analyzing the input and output of each branch, judging whether piling is needed, and if so, piling; and generating unit test codes based on all the branches, and realizing automatic generation of the unit test codes.
Referring to fig. 1, a method for automatically generating unit test codes includes the steps of:
s1, receiving the specified input and output aiming at the unit to be tested;
s2, analyzing the input and output to obtain all possible branches;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
s4, generating unit test codes based on all branches.
From the above description, the beneficial effects of the present invention are: through receiving the appointed input/output to the unit that awaits measuring, analysis input/output obtain all branches that probably exist, the input/output of each branch is reexamined, judges whether need pile, if need then pile, and based on all branches, the generation unit test code can realize automatic generation unit test code, reduces loaded down with trivial details repeated work, also can use in the maintenance in later stage, and save time has improved work efficiency.
Further, the determining whether pile driving is required in step S3 includes: traversing all output result character strings, and performing semantic analysis on the character strings in sequence; and judging whether the character string is a determined value or a return value of a method, wherein if the character string is the determined value, piling is not needed, and if the character string is the return value of the method, piling is needed.
According to the description, semantic analysis is carried out on the output result character string to automatically judge whether piling is needed, so that the workload of related personnel is reduced, and the testing efficiency is improved.
Further, the piling of step S3 includes:
s31, obtaining a subclass of the class of the depended method in an inheritance mode;
s32, rewriting the dependent method to return the dependent method of the subclass to the specified value.
From the above description, it can be seen that the efficiency of piling is improved and further implementation of the test is facilitated by automatically rewriting the relied method in the inherited subclass to return the specified value.
Further, the obtaining a sub-class of the class in which the dependent method is located after the step S31 further includes: and judging whether the class of the depended method is a final class or final method which cannot be inherited and rewritten, if so, modifying the byte code of the class of the depended method, and changing the class of the depended method into a non-final class or method.
From the above description, it can be known that by automatically judging whether the class where the relied method is located is a final class or final method which cannot be inherited and rewritten, if so, the relied method can be automatically modified into a non-final class or method, so that the piling efficiency is improved, a lot of tedious work is reduced for related personnel, and the time is saved.
Further, the step S1 further includes: and judging whether the input needs to be modified, and if so, receiving the specified modified input aiming at the unit to be tested.
According to the description, when the unit to be tested is changed, all test case codes can be regenerated only by modifying the specified input without rewriting the codes for testing, so that the method is convenient and quick, a lot of complicated and repeated work of people is avoided, and the working efficiency is improved.
Referring to fig. 2, a terminal 1 for automatically generating unit test codes includes a memory 2, a processor 3 and a computer program stored in the memory 2 and executable on the processor 3, wherein the processor 3 implements the following steps when executing the computer program:
s1, receiving the specified input and output aiming at the unit to be tested;
s2, analyzing the input and output to obtain all possible branches;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
s4, generating unit test codes based on all branches.
From the above description, the beneficial effects of the present invention are: the input and output are analyzed by receiving the appointed input and output of the unit to be tested, all branches which possibly exist are obtained by the input and output, the input and output of each branch are analyzed, whether pile driving is needed or not is judged, pile driving is conducted if needed, unit testing codes are generated based on all the branches, automatic generation of the unit testing codes can be achieved, tedious and repeated work is reduced, time is saved, and working efficiency is improved.
Further, the determining whether pile driving is required in step S3 includes: traversing all output result character strings, and performing semantic analysis on the character strings in sequence; and judging whether the character string is a determined value or a return value of a method, wherein if the character string is the determined value, piling is not needed, and if the character string is the return value of the method, piling is needed.
According to the description, semantic analysis is carried out on the output result character string to automatically judge whether piling is needed, so that the workload of related personnel is reduced, and the testing efficiency is improved.
Further, the piling of step S3 includes:
s31, obtaining a subclass of the class of the depended method in an inheritance mode;
s32, rewriting the dependent method to return the dependent method of the subclass to the specified value.
From the above description, it can be seen that the efficiency of piling is improved and further implementation of the test is facilitated by automatically rewriting the relied method in the inherited subclass to return the specified value.
Further, the obtaining a sub-class of the class in which the dependent method is located after the step S31 further includes: and judging whether the class of the depended method is a final class or final method which cannot be inherited and rewritten, if so, modifying the byte code of the class of the depended method, and changing the class of the depended method into a non-final class or method.
From the above description, it can be known that by automatically judging whether the class where the relied method is located is a final class or final method which cannot be inherited and rewritten, if so, the relied method can be automatically modified into a non-final class or method, so that the piling efficiency is improved, a lot of tedious work is reduced for related personnel, and the time is saved.
Further, the step S1 further includes: and judging whether the input needs to be modified, and if so, receiving the specified modified input aiming at the unit to be tested.
According to the description, when the unit to be tested is changed, all test case codes can be regenerated only by modifying the specified input without rewriting the codes for testing, so that the method is convenient and quick, a lot of complicated and repeated work of people is avoided, and the working efficiency is improved.
Example one
Referring to fig. 1, a method for automatically generating unit tests includes the steps of:
s1, receiving the specified input and output aiming at the unit to be tested;
the input refers to the condition of an if statement in a code, the output refers to the result when the condition is met or not, if the source code of the unit to be tested is changed, for example, three parameters are changed into four parameters, 16 test cases need to be rewritten under the traditional method, but the test cases can be automatically regenerated only by modifying the input condition;
s2, analyzing the input and output to obtain all possible branches;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
specifically, semantic analysis is sequentially performed on character strings by traversing all character strings of output results; judging whether the character string is a determined value or a return value of a method, if the character string is the determined value, piling is not needed, and if the character string is the return value of the method, piling is needed;
when piling, firstly judging whether the class of the depended method is a final class or final method which cannot be inherited and rewritten, if so, modifying the byte code of the class of the depended method, and changing the class of the depended method into a non-final class or method;
then, obtaining a subclass of the class of the depended method in an inheritance mode; rewriting said dependent method to return said dependent method of said one subclass to a specified value;
s4, generating unit test codes based on all branches.
Specifically, the test case code is generated for each branch by writing the determined value or the specified value returned by piling into the test case that meets the input condition, thereby completing the unit test.
Example two
Applying the method described in example one to a specific example, in the java test:
first, the system provides several methods for inputting parameters:
a) a method of setting a condition, (hereinafter referred to as if method), the method being for receiving a developer-supplied conditional statement, assuming that there is such a statement: return a >01:0, provided that "a > 0";
b) a method for setting a return value when a condition is satisfied (hereinafter, referred to as the then method), which is used to receive a value when a condition given in an if method provided by a developer is satisfied, and is "1" in the above statement as an example;
c) a method of setting a return value when the condition is not satisfied (hereinafter referred to as else method), which is used to receive a value when the condition given in the if method provided by the developer is not satisfied, which is "0" in the above statement as an example;
d) a method (hereinafter, referred to as "verify method") for specifying the number of times a method is executed under a condition is set, the method is used for receiving the number of times a certain statement is executed when the condition given in the if method provided by a developer is satisfied or not satisfied, because in java, a method may not have a return value, when testing such a method, it is necessary to perform the method by confirming whether the certain method is executed, and a statement input by the method is called a confirmation statement;
e) the method for outputting the case, hereinafter referred to as build method, is used for a developer to obtain all codes of the test case;
the system then enables automatic generation of unit test code by:
s1, receiving the specified input and output for the unit under test, specifically:
(1) the system receives an input condition set by a developer calling an if method;
(2) the developer calls the method, and the result obtained by the method to be tested under the condition that the method to be tested meets the condition specified in the step (1) is provided for the system in the form of character strings;
(3) the developer calls the verify method (if necessary), and provides the method to be tested to the system in the form of character string and the number of times that the method to be tested needs to be executed under the condition that the method to be tested meets the conditions specified in the step 2;
(4) the developer calls the else method (if necessary), and provides the result obtained by the method to be tested under the condition that the condition specified in the step 2 is not met to the system in the form of a character string;
(5) the developer calls the verify method (if necessary), and provides the method to be tested to the system in the form of character string and times which do not meet the conditions specified in the step 2;
(6) all the input of the developer is temporarily stored in the memory;
(7) the developer repeats the steps from (2) to (6) until all possible input and output of the method to be tested are specified to be completed;
when the input conditions of the unit to be tested need to be changed, receiving the specified modified input aiming at the unit to be tested, and modifying the conditions of the if method;
s2, analyzing the input and output to obtain all possible branches, specifically:
(1) receiving an instruction for executing the build method sent by a developer;
(2) after receiving a build instruction sent by a developer, the system traverses all input condition character strings, performs semantic analysis in sequence, and judges that the input of the method has several conditions, the conditions are combined in what form, and how many branches the combination of the conditions has, so as to determine how many test cases are generated, for example, a certain condition is "a >0& & b > 0", then the system finds that the condition is a composite condition composed of two conditions through analysis, and then 4 test cases are generated;
s3, analyzing the input and output of each branch, judging whether piling is needed, if so, piling:
specifically, the system traverses all output result character strings, performs semantic analysis in sequence, judges whether the character string is a determined value or a return value of a method, writes the test case meeting the conditions into the value if the character string is the determined value, and performs piling on the method if the character string is the return value of the method. Before the tested code runs, the system modifies the return value of the depended method by modifying the byte code of the class, and modifies the return value of the depended method to a random value which is specified in advance. Therefore, when the test case is run, the relied method returns the specified value, and the actual code logic of the relied method cannot be run, so that the purity of the tested method is ensured;
s4, generating unit test codes based on all branches, specifically:
generating a corresponding test case code for each branch, outputting the codes of the test cases of all the branches to a catalog of the same path of src/test/java/tested classes under the engineering catalog by the system, wherein all the test case codes form a test for the unit;
finally, the developer enters the catalog and runs the unit test case to realize the test of the unit.
Through the steps, a developer can obtain a plurality of complete test case codes covered by all branches of the tested method under the condition of a very small amount of input, namely actually only copying and pasting the source codes, thereby saving a large amount of time. Moreover, developers need hardly learn new content: the scheme has only a few methods, and can be ignored compared with any third-party unit testing framework. In later maintenance, the same method can obtain new test case codes, and does not need to worry about finding out which places in the original cases need to be modified, so that a large amount of time can be saved.
EXAMPLE III
Applying the method described in example two to a specific example, in the java test:
suppose that a developer is to write a unit test case to the following piece of code:
public class Foo{
public int getValue(int value1,int value2,int value3){
if(value1>0||value2>0||value3>0){
return MathTools.next(value1,value2,value3)；
}
return 0；
}
}
the core of this code has only three lines, which results in: when the three input parameters are all natural numbers, returning a return value (Mathtools. next) of a certain method of another class, and otherwise, returning 0; in order to ensure that 8 test cases are written in full branch coverage and a great deal of time is needed for later maintenance, the process is as follows under the condition of using the scheme of the invention:
s1, receiving the specified input and output for the unit under test, specifically:
(1) firstly, a developer calls an if method and inputs a condition of 'value 1>0| | | value2>0| | | value3> 0', namely a character string serving as an if statement condition in a source code;
(2) the system receives input and stores the condition 'value 1>0| | value2>0| | value3> 0' into an array;
(3) next (value1, value2, value3) "is set by the developer calling the method, which is also a character string in the source code, and the system receives the output result when the above conditions are satisfied;
(4) the developer calls the verify ("mathtools. next (value1, value2, value 3)", 1) method, and this method of "mathtools. next (value1, value2, value 3)" is executed once, with the setting of the condition "value 1>0| | value2>0| | value3> 0" being satisfied.
(5) The developer calls an else method, sets '0', and the system receives an output result when the condition is not met;
(6) the developer calls the verify ("mathtools. next (value1, value2, value 3)", 0) method, and in the case where the condition "value 1>0| | value2>0| | value3> 0" is not satisfied, "mathtools. next (value1, value2, value 3)" this method is not executed;
s2, analyzing the input and output to obtain all possible branches, specifically:
(1) a developer calls a build method to inform the construction of a test case code;
(2) after the system receives the build instruction, it starts to analyze the data in the memory, first, it is a conditional statement, in this embodiment, there is only one conditional statement, that is, "value 1>0| | value2>0| | | value3> 0", which is a composite condition, and it will be split into three conditions, respectively: value1>0, value2>0 and vlaue3>0, there will be 8 combinations of the three conditions, so the system will generate 8 test cases;
(3) the system continues to analyze the conditional statement, and judges that the conditional statement cannot be satisfied only in the case of value1< (0), value2< (0) and value3< (0), and all other 7 combinations can satisfy the condition, so that in the generated 8 test cases, the return values of 7 cases satisfying the condition are "Mathtools. next (value1, value2, value 3)", and the return value of cases not satisfying the condition is 0;
s3, analyzing the input and output of each branch, judging whether piling is needed, if so, piling, specifically:
(1) the system analyzes the output statement, the current method has two outputs, one is '0', the other is the character string 'Mathtools.Next (value1, value2, value 3)', the system judges that '0' is an integer value, and the integer value is directly given; next (value1, value2, value3) is a return value of a certain method of another class, and it is necessary to pile-drive, rewrite the depended method in a subclass in an inherited manner, giving a return value;
(2) the system analyzes the confirmation statement, and finds that the method "Mathtools. next (value1, value2, value 3)" will be executed 1 time if the condition is satisfied, otherwise, it is executed 0 times, i.e., it is not executed;
s4, generating unit test codes based on all branches, specifically:
(1) after all input and output statements are analyzed, the system assigns values according to the input conditions of each test case, namely, a random value meeting or not meeting the conditions is given, and an assignment code is generated; piling according to the requirement of piling; generating a code for calling the tested method; generating a code for judging output; generating a confirmation statement code; finally, the codes are merged and output to be a complete test case code to a specified directory;
(2) the tested method finally generates the following 8 test cases, which can be directly run and detect the result, and the codes are as follows:
a test case I:
and a second test case:
and (3) test case III:
and (4) testing a case IV:
and a test case five:
test case six:
test case seven:
and (4) testing a case eight:
if the source code of the tested method is changed, for example, three parameters are changed into four parameters, then a developer under the traditional method needs to rewrite 16 test cases, and the developer using the system only needs to modify the parameters of the if method, introduce new condition statements and execute the build method, so that the test cases can be regenerated;
the @ Prepare { mathttools.class }, lockutils.mockstatic (mathttools.class), lockutils.when (...). the tnreturn (..). the lockutils.verify, etc. in the above example code are all the contents of the third-party framework, and relevant personnel are required to learn in the conventional implementation of the test, while how to drive the pile is not required to be learned in the present invention, even what is called to be driven is not required to be known, and the system is only required to be told what to do, and all other things are to be completed by the system, and simply, in the present embodiment, a developer can complete tens of hundreds of lines of unit test codes by using only 4 lines of codes.
Example four
A terminal 1 for automatically generating unit test codes comprises a memory 2, a processor 3 and a computer program stored on the memory 2 and capable of running on the processor 3, wherein the processor 3 realizes the steps in the first embodiment when executing the computer program.
In summary, the method and terminal for automatically generating unit test codes provided by the present invention receive the input and output specified for the unit under test, analyze the input and output to obtain all possible branches, analyze the input and output of each branch to determine whether piling is required, if necessary, piling is carried out, the unit test codes are generated based on all branches, the automatic generation of the unit test codes can be realized, the fussy and repeated work is reduced, the device can be used in the later maintenance, the time is saved, the working efficiency is improved, whether the pile needs to be driven or not and the pile needs to be driven automatically can be judged automatically through semantic analysis, the pile driving efficiency is improved, the testing efficiency is further improved, unit testing codes can be regenerated only by modifying input when different units to be tested are tested, and the method is simple and convenient, easy to operate and convenient to use.
The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all equivalent changes made by using the contents of the present specification and the drawings, or applied directly or indirectly to the related technical fields, are included in the scope of the present invention.
Claims (8)
1. A method for automatically generating unit test codes, comprising the steps of:
s1, receiving specified input and output aiming at the unit to be tested, wherein the input refers to the condition of an if statement in the code, and the output refers to the result when the condition is met or not met;
s2, analyzing the input and output to obtain all possible branches, specifically:
traversing all input condition character strings, sequentially performing semantic analysis, and judging that the input of the method has several conditions, wherein the conditions are combined in what form, and the combination of the conditions has how many branches, so as to determine how many test cases are generated;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
the determining whether pile driving is required in step S3 includes:
traversing all output result character strings, and performing semantic analysis on the character strings in sequence;
judging whether the character string is a determined value or a return value of a method, if the character string is the determined value, piling is not needed, and if the character string is the return value of the method, piling is needed;
s4, generating unit test codes based on all branches, specifically:
the test case code is generated for each branch by writing the determined value or the specified value returned by piling into the test case that meets the input condition, thereby completing the unit test.
2. The method of automatically generating a unit test code according to claim 1, wherein said step S3 said piling comprises:
s31, obtaining a subclass of the class of the depended method in an inheritance mode;
s32, rewriting the dependent method to return the dependent method of the subclass to the specified value.
3. The method for automatically generating unit test code according to claim 2, wherein said step S31 is preceded by the step of:
and judging whether the class of the depended method is a final class or final method which cannot be inherited and rewritten, if so, modifying the byte code of the class of the depended method, and changing the class of the depended method into a non-final class or method.
4. The method for automatically generating unit test code according to claim 1, wherein said step S1 further comprises:
and judging whether the input needs to be modified, and if so, receiving the specified modified input aiming at the unit to be tested.
5. A terminal for automatically generating unit test code, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:
s1, receiving specified input and output aiming at the unit to be tested, wherein the input refers to the condition of an if statement in the code, and the output refers to the result when the condition is met or not met;
s2, analyzing the input and output to obtain all possible branches, specifically:
traversing all input condition character strings, sequentially performing semantic analysis, and judging that the input of the method has several conditions, wherein the conditions are combined in what form, and the combination of the conditions has how many branches, so as to determine how many test cases are generated;
s3, analyzing the input and output of each branch, judging whether piling is needed, and if so, piling;
the determining whether pile driving is required in step S3 includes:
traversing all output result character strings, and performing semantic analysis on the character strings in sequence;
judging whether the character string is a determined value or a return value of a method, if the character string is the determined value, piling is not needed, and if the character string is the return value of the method, piling is needed;
s4, generating unit test codes based on all branches, specifically:
the test case code is generated for each branch by writing the determined value or the specified value returned by piling into the test case that meets the input condition, thereby completing the unit test.
6. The terminal for automatically generating a unit test code according to claim 5, wherein said step S3 said piling comprises:
s31, obtaining a subclass of the class of the depended method in an inheritance mode;
s32, rewriting the dependent method to return the dependent method of the subclass to the specified value.
7. The terminal for automatically generating unit test code according to claim 6, wherein said obtaining a subclass of a class in which dependent methods are located after step S31 further comprises:
and judging whether the class of the depended method is a final class or final method which cannot be inherited and rewritten, if so, modifying the byte code of the class of the depended method, and changing the class of the depended method into a non-final class or method.
8. The terminal for automatically generating unit test codes according to claim 5, wherein said step S1 further comprises:
and judging whether the input needs to be modified, and if so, receiving the specified modified input aiming at the unit to be tested.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811004196.6A CN109308260B (en) | 2018-08-30 | 2018-08-30 | Method and terminal for automatically generating unit test code |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811004196.6A CN109308260B (en) | 2018-08-30 | 2018-08-30 | Method and terminal for automatically generating unit test code |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109308260A CN109308260A (en) | 2019-02-05 |
| CN109308260B true CN109308260B (en) | 2021-11-05 |
Family
ID=65224090
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811004196.6A Active CN109308260B (en) | 2018-08-30 | 2018-08-30 | Method and terminal for automatically generating unit test code |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109308260B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101145954A (en) * | 2007-06-20 | 2008-03-19 | 中兴通讯股份有限公司 | Implementation method for piling class of communication function |
| CN101436128A (en) * | 2007-11-16 | 2009-05-20 | 北京邮电大学 | Software test case automatic generating method and system |
| CN101706753A (en) * | 2009-12-11 | 2010-05-12 | 武汉虹信通信技术有限责任公司 | Unit testing framework and method based on Perl |
| CN102419728A (en) * | 2011-11-01 | 2012-04-18 | 北京邮电大学 | Method for determining software test process sufficiency based on coverage rate quantitative indicators |
| CN103714000A (en) * | 2013-12-18 | 2014-04-09 | 杭州电子科技大学 | Sensitive area-oriented embedded software test case generating method |
| JP2014063415A (en) * | 2012-09-24 | 2014-04-10 | Mitsubishi Electric Corp | Test case automatic generation device and test case automatic generation program |
| CN106874202A (en) * | 2017-02-14 | 2017-06-20 | 网易无尾熊（杭州）科技有限公司 | Method, device and readable storage medium storing program for executing for unit testing |
| CN107992425A (en) * | 2017-12-25 | 2018-05-04 | 携程旅游网络技术（上海）有限公司 | The automatic generation method and system of unit testing Mock codes |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7334219B2 (en) * | 2002-09-30 | 2008-02-19 | Ensco, Inc. | Method and system for object level software testing |
-
2018
- 2018-08-30 CN CN201811004196.6A patent/CN109308260B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101145954A (en) * | 2007-06-20 | 2008-03-19 | 中兴通讯股份有限公司 | Implementation method for piling class of communication function |
| CN101436128A (en) * | 2007-11-16 | 2009-05-20 | 北京邮电大学 | Software test case automatic generating method and system |
| CN101706753A (en) * | 2009-12-11 | 2010-05-12 | 武汉虹信通信技术有限责任公司 | Unit testing framework and method based on Perl |
| CN102419728A (en) * | 2011-11-01 | 2012-04-18 | 北京邮电大学 | Method for determining software test process sufficiency based on coverage rate quantitative indicators |
| JP2014063415A (en) * | 2012-09-24 | 2014-04-10 | Mitsubishi Electric Corp | Test case automatic generation device and test case automatic generation program |
| CN103714000A (en) * | 2013-12-18 | 2014-04-09 | 杭州电子科技大学 | Sensitive area-oriented embedded software test case generating method |
| CN106874202A (en) * | 2017-02-14 | 2017-06-20 | 网易无尾熊（杭州）科技有限公司 | Method, device and readable storage medium storing program for executing for unit testing |
| CN107992425A (en) * | 2017-12-25 | 2018-05-04 | 携程旅游网络技术（上海）有限公司 | The automatic generation method and system of unit testing Mock codes |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109308260A (en) | 2019-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20210209008A1 (en) | Unit testing method based on automatic generation of path coverage test cases | |
| US7895575B2 (en) | Apparatus and method for generating test driver | |
| CN110008113B (en) | Test method and device and electronic equipment | |
| US11733975B1 (en) | System and method for migrating legacy software to a system common architecture | |
| US20060248405A1 (en) | Method for automating unit test development | |
| CN109189479B (en) | Parallel automatic verification method for processor instruction set | |
| CN103631720A (en) | Method and device for generating test case | |
| CN110633200A (en) | Method and device for testing intelligent contracts | |
| US20150220424A1 (en) | Test double generation | |
| Techapalokul et al. | Code quality improvement for all: Automated refactoring for Scratch | |
| Khatchadourian et al. | [Engineering Paper] A Tool for Optimizing Java 8 Stream Software via Automated Refactoring | |
| Chen et al. | Bad smells and refactoring methods for gui test scripts | |
| Cheon et al. | Converting Android native apps to Flutter cross-platform apps | |
| CN109308260B (en) | Method and terminal for automatically generating unit test code | |
| CN111142861B (en) | Method and device for integrating structured comprehensive control system | |
| Clerissi et al. | Test driven development of web applications: A lightweight approach | |
| CN112256572B (en) | Random test case generation method and device, electronic equipment and storage medium | |
| WO2022156056A1 (en) | Program source code reslicing-based software dynamic update hot patch synthesis method | |
| CN109144849A (en) | A kind of embedded software adjusting, measuring method | |
| Schmolitzky | " Objects first, interfaces next" or interfaces before inheritance | |
| JP2002116911A (en) | Automatic generation device for object-oriented program | |
| Rosu | CS322 Fall 2003: Programming Language Design-Lecture Notes | |
| Yogesh et al. | Test-driven development of automotive software functionality | |
| CN116166567B (en) | Test case generation method and device based on graphic programming | |
| Orjala | Unit testing methods for Internet of Things Mbed OS operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |