How can we develop practical plans for unit testing (Java?

Q:

 

A new test user writes a unit test case template based on his own understanding. However, the developer (Java language) is hard to implement and does not know how to correct it. My original idea was to use classes as a unit, to ensure the test coverage rate, first draw a control flow chart and determine the input and output based on the independent path. If you have input and output, it is a use case. However, it is difficult to draw a control flow chart in units, classes may involve many functions, and each function has its own control flow diagram with different complexity.
Confused. I'm totally confused about how to plan it ~

 

A:

 

1. tests are carried out in the unit of class, which is out of reality. The test of a function may be very complicated. The unit of class is not feasible. We recommend that you change the unit of function to test only algorithm-intensive functions, simple functions do not need to be tested.

2. it is not practical to use the base Path Method in case design. Cause:
1) The efficiency is too low and too troublesome. If you have more than 50 rows of functions, you can draw a flowchart to ensure that the system is dizzy.
2) The overwrite intensity is too low, but only the statement overwrites;
3) This is a case design method out of program functions. If the use case does not set the correct expected output based on the function, the test will be meaningless, and the pure white box method cannot find the missing code error. Therefore, use cases should be designed from the functional perspective first.

Iii. Recommended template and test process should be changed:
A. List function points;
B. Design a use case for each function;
C. Find a coverage tool, calculate coverage, and then design use cases for uncovered logical units.

4. Books are often separated from reality, and the unit test field is the hardest hit area.

5. read this article. This is C ++, but the truth is the same: the correct application of the white box method in case design.Q:Thank you ~~~~ I suddenly realized that some people have said that the black box test should be performed based on the function, the coverage rate should be calculated, and the use case should be supplemented to cover untested units. I didn't care about it at the time. Now I am so grateful for hearing from you ~ I still have some questions after reading your post. It seems that the use of tools can completely Save the work of writing driver modules and pile modules,
Can I use the JUnit package for Java to automatically generate case data and coverage rate statistics in eclipse? Or are there other tools that can be used together?
This is the case of input and output. If there is no input and output or other operations, how should we test it? Please advise me again ~A:Sorry, I am mainly engaged in unit testing for C/C ++. I have never performed Java unit testing and are not familiar with related tools.
In general, unit tests in Java are easier, because the new language considers the support for unit tests during design. There are also a lot of related tools. Find them by yourself.
It seems that JUnit cannot generate a pile and a drive, right? I have never used it. Generating piles and driving are repetitive, which is the most suitable tool. There should be dedicated tools for coverage statistics, as if there were open-source tools.

Input and output are not just parameters and return values. The input also includes: member variables, global variables, and internal input. Internal input is the input obtained by calling the sub-function and the local static variable. The output also includes output parameters, member variables, global variables, and internal output. The internal output is the intermediate result. For example, if a program calculates a piece of data and sends it directly without returning it, it must be determined whether it is correct or not.

If none of the above input and output are available, such a function usually only plays an integrated role and has no computing, for example:
Void func ()
{
Func1 ();
Func2 ();
Func3 ();
}
There is no need to perform unit tests for such functions. Just read the code. Unit testing applies to algorithm-intensive functions. In addition, I would like to give you a suggestion:
Unit testing is not an easy task. Don't promote it all at once. You need to find some code to test the tool and process, and remove unnecessary links, if possible, you should first find one or two programmers to discuss and try to promote the program only when it is mature.