Ruby --一种基于TDD/BDD的实用软件测试方法

Question

虽然TDD/BDD是理想的，而且由于时间有限，但您不能总是有100%的测试覆盖率，并且总是在实现特性之前编写测试，那么，您有什么方法可以让一个经过良好测试的项目在很短的时间内完成呢？

我最初的想法是：

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

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

1. 集成测试

最后提交给QA进行手动测试，如果发现了错误，则添加

1. 单元测试

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

Answer 1

免责声明:我被测试感染了

这是一方面的信心与另一端的短期交货速度之间的滑动尺度。你不能两者兼得。你可以通过向右滑动来运输得更快。最佳职位取决于你的工作环境(团队技能、项目不确定性/风险、组织文化、日程安排等)。

至于上面的过程大纲，我可能看错了。看来你在为速度而分出单元测试。即不使用TDD的ATDD。

如果这是你要去的地方，我看到以下风险

• 验收测试很麻烦:它们会告诉您某些东西失败了--但是无助于缺陷隔离，。相同的验收测试可能由于多种原因而失败/多个系统测试可能因同一错误而失败。你可能会失去很多时间去追查原因。集中的单元测试应该立即告诉您问题的确切位置。随着时间的推移，调试验收测试失败的时间可能会超过不编写聚焦测试所节省的时间。
• 验收测试是缓慢的:与单元测试相比，您只能在5分钟内运行少数(乐观的)大量测试。在那里你可以在同一时间进行数以千计的微测试。这很有帮助，因为单元测试将给您更快的反馈，它更接近破坏某些东西的代码更改。因为它们需要时间运行，所以通常的趋势是以最少的次数运行验收测试。更多的时间花在识别破坏应用程序后背的确切的代码更改上。
• 验收测试是不彻底的:不能涵盖每一个微小的边缘情况，因为它将导致不可行的测试套件执行时间。臭虫可以在那些未经测试的地方繁殖。

最后，IMHO接受/系统测试应该是最后的防御级别，而不是第一个。我见过团队在代码质量问题上苦苦挣扎，团队对代码质量缺乏诚意，并且依赖于系统测试来捕捉一切；正如上面所说的，这是在欺骗自己。TDD对代码质量有更直接的影响。ATDD只会告诉你某些东西坏了/它对客户来说是不可接受的。也就是说，取决于团队中discipline+experience的正确组合，它可能在短期内起作用。只是我不赌。

如果您想减少单元测试所需的时间，请与团队一起讨论并定义关键/焦点领域/模块。用TDD把这些做完。