读《Software Engineering at Google》（13）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（13）—— Test Doubles

• 📖：@Google，test double，指在测试中和在实用中，有相同的表现。

  🤔：测两次，Test Doubles，才两次嘛，还是重复一次，有点困惑。这看起来不高级呀，不就是测试通过，实用环境也符合预期嘛。这么说是否有点小看谷歌？当然，这比不过我看到 Design Twice 时，那种无处安放的惊讶感。在某些领域的某些点上，我自己干过 Twice 以上，但是，从来就没想过，在某次迭代里，来个 Design Twice。不知道是头皮发痒，还是屁股发痒，非得挨揍一次，才发现会迷恋上这种味道。我已经在刻意寻找 Design Twice 的机会，噢，刻意的说法是谎言，实际上是，下次逮到就要去尝试，就是为了去痒一下，可靠能否碾压到自己的思维。

  🤔：不过，细想起来，如果在测试时的行为和结果，真得符合实际环境的预期，不是件容易的事情。假设我的测试代码在 x64 的服务器上验证，这个环境可能有 32 个 CPU 核心，一切都顺利通过，很开心的样子。可是，我能回答，在 ARM926 的环境里，在 F32 单片机的环境里，被测代码还能跑得符合预期嘛？我给自己出了个难题，难在我自己都不知道怎么回答。忽然间，又想起“模拟器（Simulator）”和“仿真器（Emulator）”，曾经也为此困惑过，尤其是被它的市场价格迷惑，后者到底比前者贵在哪方面。曾经猜测，前者是“软”实现，后者是“硬”家伙，按分量称重，自然是后者贵点。实在不好意思，这只是个找不到答案时的调侃。某天忽然想明白，如果我在仿真中的效果，跟实际硬件的效果完全一致，这意味着稳定的预期，更意味着仿真的结果靠谱。尤其是，在实际验证环境搭建需要巨额成本的时候，典型就是芯片类仿真。而之前嵌入式硬件同样具有昂贵的特性，因此需要仿真先上场，即使仿真器很贵，但是整体核算下来，在前期就排查掉问题，是非常有利于后期的风险和成本控制。只是吧，在嵌入式硬件廉价的今天，大家已经忘记曾经 nnK 刀开发版的价位，更是忘记曾经没法子到手的芯片。

• 📖：

    —— By 术子米德 @2022.04.21