开发后测试的缺陷是什么？

Question

最近我被分配到一个已经处于中途的项目。这是TDD环境。 每个人都遵循代码单元测试优先和实施代码的正确原则。但是，情侣正在反向做，首先是实施代码，然后是单元测试。

虽然在辩论中，他们说两种方式都类似。

如果首先执行代码并稍后执行单元测试，可能会出现哪些潜在问题？

Answer 1

• 过度工程 - 你可能写了比实际需要更多的代码。
• 偏见 - 您可以编写测试实施而不是要求的测试。
• 测试不会驱动您的设计 - 测试可以表明设计改进。随着时间的推移，您的设计会变得僵硬并且不愿意改变。
• 让您放慢速度 - 您的实施可能会出现可测性问题，只有在您尝试编写测试时才会出现问题。到那时，你可能会倾向于解决问题，因为现在测试正在阻碍你实现下一个功能。尝试对不可测试的blob进行单元测试是令人沮丧的..通常情况下，你最终会进行非彻底的测试（测试什么是容易的并继续前进）。
• 可能无法编写测试 - 一旦您的实现准备就绪并且您已经手动验证它可以工作，就会跳过无聊的单元测试并跳到有趣的部分...编写更多代码。随着时间的推移，未经考验的混乱。

如果不够明显，请先测试FTW！

Answer 2

始终鼓励在实施前进行测试。除了实际修复软件中可能存在的错误之外，它还有助于清除代码中需要的代码，因为工程师可能会“过度编码”。

我总是告诉自己“如果我正在为飞机自动驾驶仪编写软件，我该怎样做才能确保自己该软件从不失败？”在测试软件之前，这些人是否会反过来让他们的家人进行自动驾驶？像这样思考有助于为软件工程提供一种规范的方法。

Answer 3

首先编写测试并执行后确保您正在编写肯定会通过测试的实现代码。首先实现并编写测试代码之后会遇到固有的风险，即您必须重构（有时是显着的）实现代码以确保正确的测试覆盖率，这可能会变得很昂贵，具体取决于这些测试的编写时间。

个人经验，我看到最好的生产力/媒介来自开发人员在实施过程中同时进行测试，做足够的事先确保接口合同的边界被正确锁定并且值得测试，留下测试这不会导致重新设计/主要重构，但在完成一系列单元测试之前不会考虑组件完成。