读《Software Engineering at Google》（12）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（12）—— Unit Testing

• 📖：@Google，所谓 Unit Test 指相对较窄的范围，典型如类或方法，虽然 Unit Test 比较小，但是不绝对如此。鼓励工程师写 80%单元测试，和其它更大范围的测试。并且重点关注测试的可维护性，达到测试过就安心的状态，停下来的原因就是测试失败。（🤔：重点维护测试用例，其次再是生产代码，这需要见识和勇气，更是时间后成熟心态和行为的体现，一种从容不迫、自信满满感在电子屏幕上溢出来）

  🤔：单元测试，2020 年初疫情，在家办公时，就在讨论单元测试，以及它是否能够自动化，谁也说服不了谁，也没有说服自己。现在回看，那时候的我，跟个技术 ShaZ 差别不大。现在 2 年过去，关于 UT 的认知、实践和反思，有质的飞跃性。不过吧，我期望 2 年后，再来回看现在的自己，又像个 ShaZ 一样，这才是我期盼的成长。只有过段时间回看自己，简直认不出那个 ShaX 是谁，才是我该有的成长节奏。这也就是说，如果看到过去的自己很 NiuX 的样子，只能说明没有任何进步，难听点说，更是在倒退路上下滑。

  🤔：现在，我会把 UT 挂在嘴边，我也会把 UT 挂在任何实现代码的边上，就像现在的笔记，就是写在我人生的边上一样。我自己参与的代码实现，如果没有写相应的 UT，哪怕仅仅是典型使用类的 UT，就像自己在吃红烧牛肉，还是在吃刺身牛肉的差别。这里，我不得不稍微补充一下，关于刺身牛肉的体验，那是一种在公共场合，把呕吐路径直接反向的尴尬和难受。所以，我现在如果不写 UT，就会有负罪感，仅看到实现代码，没有 UT 代码，就会有呕吐感。

  🤔：关于 UT 的认知，最深刻的就是，首先，所谓 UT 是指测试用例的单位，即 Test Case Unit，少个 Case、换个顺序，就是这么大误解。而这里的 Unit 是指 Test Case 的单元性，即以测试用例为单位，尤其指运行时刻的单元性，即第 N 个用例的执行，无论成功或失败，尤其是失败的情况下，不能影响 N+1 个用例的执行。这里其实包含两层意思，第一层就是如前阐述，测试用例之间要有单元性，彼此之间不能有影响，第二层意思更关键，那就是 UT 必须是自动化，至少也是批量化。否则的话，一个例子失败又如何，手动下一个不就可以了嘛，实在不行手动恢复一下测试环境不香嘛。在 UT 的语境里，这是臭极了，更是丑极了。其次，Unit 指被测对象，或者高级点叫做被测系统，术语为 SUT=System-Under-Test，这个 Unit 是在具体场景里，根据实际需要重新定义。而我之前就是被某些编程语言，宣称的单元测试特性概念影响，一直带着这个误解和偏见。所以，总的来说，UT 要自己定义单位，UT 必须自动化。

  
  

    —— By 术子米德 @2022.04.20