系统测试集成测试单元测试
每周写一篇博客文章需要大量灵感。 幸运的是，Twitter在那里。
这次，是以下推文引发了大火。
我最近一直没有关注Twitter的技术博客，但有一篇有趣的测试文章。 https://t.co/wiej11QoM1
— Cindy Sridharan（@copyconstruct） 2018年1月9日
-功能测试比类测试（单元测试）好得多*
-功能测试比单元测试的优势
-重构代码不应涉及重构测试pic.twitter.com/6JunHDJksl
虽然我知道Twitter并不是微妙而复杂的想法的发源地，但我相信这种方法弊大于利。 考虑到我将大量时间用于各种类型的测试，设计和编写测试，我相信我的观点可以为您带来一些帮助。
无耻的插件在您学习它的同时，请阅读我的《 Trenches集成测试》一书，该书专门介绍，猜测什么是集成测试。
根据定义，一条推文并不意味着提供支持某人观点的详细论据。 因此，让我们检查一下原始帖子中的声明。
定义
就像在帖子中一样，由于单元的范围，我发现术语“单元测试”含糊不清。 同样，术语“集成测试”可以指不同人头脑中的不同事物。
在本文的其余部分，我将遵循本文中提出的术语。
达成一致非常重要：在《 Google如何测试软件》一书中，作者使用测试的执行速度对测试进行分类（小，中，大）。在我的书中，我将两个术语保持原样，但明确定义其含义。
“重构的安全网”
设计正确的功能测试可提供全面的代码覆盖范围，并且无需重写，因为它们仅使用公共API。 尝试重构仅具有单类测试的系统通常很痛苦，因为开发人员通常必须同时完全重构测试套件，从而使安全网无效。 这会激发黑客入侵，增加技术债务
我完全同意有关测试公共API的第一部分。
第二部分则更加细微： “试图重构仅具有单类测试的系统通常很痛苦。”
这是很合理的。 如果您仅有的测试是单类测试，则重构将破坏这些测试。 在那种情况下，您不知道重构是否引入了回归。
“测试端到端行为”
仅在单类测试中，如果模块之间的接口发生故障，则测试套件可能会通过，但功能可能会失效。 功能测试将验证端到端功能行为并捕获这些错误。
那里有一个重要条件： “仅进行单类测试” 。
是的，仅由单一类测试组成的测试工具无法确保整个系统按预期工作。
在介绍测试时，通常使用以下比较：让我们考虑一下汽车的制造。 单级测试类似于分别测试每个螺母和螺栓。 试想一下，对此类组件的测试没有发现任何问题。 但是，如果没有制造原型并将其发送给试驾，则大规模生产汽车仍存在很大风险。
“写更少的测试”
功能测试通常比单类测试覆盖更大的系统容量
同样，没有什么不同之处。
不过，我发现该声明有些奇怪，因为这并不是真正的优势。 尽管编写更少的功能测试以涵盖与单类测试相同的范围，但它们却变得更大。
测试的规模是功能测试中的一个问题，因为在测试失败的情况下，很难确定根本原因。 测试范围越大，分析就越困难，有关更多详细信息，请参见下一部分。
“我的功能测试坏了，它比单类测试更难调试。”
想一想如果客户报告新错误，您将花费多少时间。 首先，您花时间尝试重现该错误。 接下来，您必须调试并解决问题。 最后，您必须编写单类测试。 通常，仅重现该错误将比调试功能测试花费更多的时间。 实际上，如果您在调试经过适当设计的功能测试时遇到问题，实际上与调试整个服务器相同，并且我们断言在调试服务器时遇到更大的问题。
在这一点上，我开始不同意。
首先，我认为不能在功能测试中捕获生产错误。 如果真是如此，那么为什么在生产系统中允许该错误，而在部署之前却未修复该错误？
然后，有一个大胆的声明： “如果您在调试正确设计的功能测试时遇到麻烦” 。 这看起来像是没有真正的苏格兰人的逻辑谬误。 因为如果我在调试功能测试时遇到问题，那么作者可以随时回答设计不当的问题。 但是，他没有提供有关如何以适当方式设计功能测试的建议。
结论
我可以继续，但是我认为我是正确的。 在开始时，作者注意不要反对单类测试和功能测试，而是继续尝试证明后者优于前者。 相反，我认为它们是相辅相成的。
保持与汽车的上述类比，有人会组装原型汽车并将其发送到试驾，而无需分别测试每个螺母和螺栓吗？ 可能不是，因为如果汽车在试驾中撞车：
- 需要花时间和精力来了解根本原因
- 如果根本原因是一个螺母/螺栓出现故障，则可以以更少的时间/精力来更早地发现它
猜猜是什么，它直接转化为功能测试的一些缺点：
- 难以调试
- 慢
当然，功能测试比单类测试具有优势。 但是单类测试也超过了功能测试。
我认为人们很容易抛弃测试金字塔。
如果您想了解有关常规测试和特定于集成测试的更多信息，请不要忘记从Trenches中检查Integration Testing 。
系统测试集成测试单元测试
2127
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
