Plus knowledge supports two unit test methods.
· Exhaustive unit test
Comprehensive unit tests are required in the automobile industry and medical care. Severe unit tests that require winAMS based on criteria such as C0, C1 and MC / DC coverage rate may be required. In that case, a lot of man-hours are required, and sometimes it is not uncommon to have to write the same unit test case as the source code. Is not it difficult to perform large quantities of unit test cases in-house due to time constraints and cost constraints? In that case, please consult us first, the unit test expert will create a unit test that covers the target coverage rate and we will consult with you about how much consulting our company can do unit test. For example, we are doing unit tests to the coverage below, etc. We provide optimal unit test solution for customers from experienced rich unit testing etc.
· Hotspot unit test
If it is not a mission-critical product, it is hard to say that the quality is bad, but the cost of testing is not that much.
If so, it is not a bad idea to think that it is sufficient to cover only the places that should be covered (where bugs come out), rather than covering all the codes. In the days of old days, studies have been made to calculate complexity and bugs occur in complicated places in the program, but in modern times it is said that bugs occur in places where many file changes occur [KIM 07]. Companies that test such places as Hotspots and test only that place are increasing, including Google (http://google-engtools.blogspot.com/2011/12/bug-prediction-at-google.html), and so on. For example, since the file on the left in the figure below has been changed a lot in the nearest time, it is easy for bugs to occur, and the file on the right in the figure below is not changed so much, so it is difficult for bugs to occur and the Hotsport value is low.
If you use this theory, it will not be a dream to bust more than 80% of bugs, for example only by unit testing a 10% file!
[KIM07] S. Kim, T. Zimmermann, E. Whitehead Jr, and A. Zeller. Predicting faults from cached history. In Proceedings of the 29th international conference on Software Engineering, pages 489–498. IEEE Computer Society, 2007.