读《Software Engineering at Google》（14）

🤔☕️🤔☕️🤔

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

• 📖：@Google，小测（small tests）约束在单线程、单进程、单机器的范围，大测（larger tests）去掉这些约束。

  🤔：我写个模块，我想写测试用例，先设想单线程使用场景，再设想多线程使用场景，依此往下就会多进程。这是一种自然而然，至少在看到小测和大测之前，实际就是在这么做的。现在忽然告诉我，小测的时候，只是单线程、单进程，会觉得是不是简单了点。从经验上来说，设计和实现为单线程模式，还是多线程模式，甚至多进程模式，要考虑的因素和实现的难度，都有明显的差别。可是，小测的时候居然只在单线程、单进程验证，没有完全理解这么的好处是什么。唯一说得上来，那就是小测的例子容易构建，也能够快速迭代出一个版本。只要验证接口没有问题，那么后续可以重构出支持复杂场景的版本。果真如此嘛，不是很确定，但现在只想到这个可能性。

  🤔：对于 UT 的普遍认识，就是它得小、它得快，这个没毛病，我也这么认可，我也这么实践。当验证一个完整的模块，这是一个很普遍，也非常有效的验证单位。我就把这个模块，即所谓的被测对象，定义为一个单元，以它为单位的用例，我依然叫它们为 UT。这时候，我在工位，手动触发这些 UT，我期望快速跑完。下班的时候，我还想触发这些 UT，期望它们跑一个晚上。原因在于，好多问题短时间跑不出来，不对，这真的是原因嘛，先算吧。而到放假的时候，尤其来个七天长假，我又期望这些 UT 一直跑着，至少能验证，或者说，心里打算去验证，模块在较长时间运行后，依然符合预期。这里就有两个矛盾点出现，一方面，如何能够让 UT 既跑得快、又跑得久，还不能太大，另一方面，为何非得跑这么久，短时间的测试，能够证明什么，不能够证明什么，长时间的测试，怎么理解能够验证出更多问题。如何能够把这两个矛盾点梳理清楚，我有点呆住了，好像在拷问自己。就经验而言，跑得久，只是在结果上显得符合预期，是否需要在 UT 的设计和写法上，也与短小 UT 不一样。或者说，短小 UT 的大量长时间重复，有什么实际意义。再或者说，扩展到多大多长 UT，才算为长期做出正确的准备。终于把自己给逼问到墙角。暂时我拿不出不让自己卡壳发呆的答案。

  🤔：换个角度再问自己，如果一个单位的逻辑很清晰，验证这个单位的用例，也能做到完整和完备，那为何还会有更多重复和更长时间的验证需求？问题是不是在于，所谓的完整和完备，是否真的能做到字面意思。我写下完整和完备，并不等于就能做到完整和完备，我所谓逻辑清晰，那到底什么算清晰的逻辑？这么说来，寻找一个模型，是不是得是个数学模型，再怎么地，也得是画出来不错综复杂的示意图，再加上可数可枚举的用例，是否就在逼近清晰、完整、完备。算个路子，得去探索一番。

    —— By 术子米德 @2022.04.14