Read software engineering at Google (14)

read 《Software Engineering at Google》（14）—— Larger Testing

：@Google, Microtest （small tests） Constrained in a single thread 、 Single process 、 Range of single machine , Large measurement （larger tests） Remove these constraints .

： I write a module , I want to write test cases , Imagine a single thread scenario , Imagine the multithreading scenario , In this way, there will be more processes . This is a natural , At least before you see the small test and the big test , That's what you're actually doing . Now suddenly tell me , During the quiz , Just a single thread 、 Single process , I think it's a little simpler . Empirically , Designed and implemented in single thread mode , Or multithreading mode , Even multi process mode , The factors to be considered and the difficulty of implementation , There are obvious differences . But , During the small test, it was only in a single thread 、 Single process verification , I don't fully understand the benefits of this . The only thing I can say , That's an example of a small test. It's easy to build , It can also quickly iterate out a version . As long as there is no problem verifying the interface , Then you can reconstruct a version that supports complex scenes later . If so , I'm not sure , But now I only think of this possibility .

： about UT General understanding of , It's just that it's small 、 It's fast , There's nothing wrong with this , I agree , I also practice like this . When verifying a complete module , This is a very common , It is also a very effective verification unit . I'll take this module , The so-called tested object , Defined as a unit , Use cases in it , I still call them UT. Now , I'm at the station , Trigger these manually UT, I expect to run fast . After work , I also want to trigger these UT, Expect them to run all night . The reason lies in , Many problems can't come out in a short time , incorrect , This is really the reason , Let's do it first . And when it comes to holidays , Especially for a seven day holiday , I expect this again UT Running all the time , At least verify , Or say , I intend to verify it , The module runs for a long time , Still in line with expectations . There are two contradictions here , One side , How to make UT Both run fast 、 Run for a long time again , Not too big , On the other hand , Why do you have to run so long , A short test , Can prove anything , Can't prove anything , A long test , How to understand can verify more problems . How can we sort out these two contradictions , I'm kind of stuck , It's like torturing yourself . In terms of experience , Run long , It just seems to meet expectations in the results , Is it necessary to UT In the design and writing of , Also with short UT Dissimilarity . Or say , Short UT A lot of long repetitions , What practical significance . Or , How big and how long UT, To make the right preparation for the long term . Finally he forced himself into the corner . For the time being, I can't get the answer that I won't get stuck in a daze .

： Ask yourself from another angle , If the logic of a unit is clear , Verify the use case of this unit , Can also be complete and complete , So why are there more repetitions and longer validation requirements ？ The question is whether , The so-called integrity and completeness , Can you really take it literally . I write complete and complete , It doesn't mean you can be complete and complete , The so-called logic is clear , What exactly is clear logic ？ In this way , Looking for a model , Does it have to be a mathematical model , No matter what , You have to draw a good and complex diagram , Plus countable and enumerable use cases , Whether it is approaching or not 、 complete 、 complete . Figure out a way , We have to explore .