Ruby - 使用TDD / BDD进行软件测试的实用方法

Question

虽然TDD / BDD是理想的，并且随着时间的限制，你不能总是拥有100％的测试覆盖率并且在实现功能之前总是编写测试，那么，你有什么方法可以在紧张的时间内完成一个经过良好测试的项目？

我最初的想法是：

1. 使用RSpec的验收测试
2. 开发
3. 返回1

在验收测试/开发周期的几次迭代之后，我将添加

1. 集成测试

最后发送到QA进行手动测试，如果发现错误，则添加

1. 单元测试

您认为上述工作流程合理吗？

Answer 1

免责声明：我是受测试感染的

这是一方面的信心和另一方面的短期交货速度之间的滑动比例。你不能两者兼得。通过向右滑动可以更快地发货。最佳位置取决于您的背景（团队技能，项目不确定性/风险，组织文化，进度等）

至于上面的流程大纲，我可能读错了。看来你正在为速度进行单元测试。即没有TDD的ATDD。

如果您正在前进，我会看到以下风险

• 验收测试很粗糙：他们会告诉你某些事情失败了 - 但无法帮助解决缺陷问题。同样的验收测试可能因各种原因而失败/多个系统测试可能因同一个错误而失败。您可能会失去大量时间来追踪原因。集中的单元测试应该立即告诉您问题的确切位置。随着时间的推移，调试验收测试失败所花费的时间可能会超过不编写焦点测试所节省的时间
• 验收测试很慢：与单元测试相比，您可以在5分钟内仅运行少量（乐观）大块测试...您可以在同一时间运行数千个微测试。这有用的原因是单元测试会给你更快的反馈更接近破坏某些东西的代码更改。由于它们需要时间来运行，因此通常的趋势是以最少的次数进行验收测试。花费更多时间来确定破坏应用程序的确切代码更改。
• 验收测试不彻底：不能覆盖每一个微小的边缘情况，因为它会导致不可行的测试套件执行时间。虫子可以在那些未经检验的地方繁殖。

最后恕我直言的验收/系统测试应该是最后一级防御;不是第一个。我见过团队在代码质量问题上苦苦挣扎，团队对代码质量并不诚恳，依靠系统测试来捕捉所有内容;如上所述，这是在欺骗自己。 TDD对代码质量有更直接的影响.ATDD只会告诉你某些东西被破坏/它对客户来说是“不可接受的”。也就是说，根据团队的正确组合和经验，它可能会在短期内发挥作用......只是我不会赌它。

如果您想减少单元测试所需的时间，请与团队坐下来定义关键/重点区域/模块。用TDD完成那些。