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

Question

虽然 TDD/BDD 是理想的，但由于时间有限，您无法始终拥有 100% 的测试覆盖率，也无法始终在实现功能之前编写测试，那么，您采用什么方法来在紧迫的时间安排下完成经过良好测试的项目？

我最初的想法是:

1. 使用 RSpec 进行验收测试
2. 发展
3. 回到1

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

1. 集成测试

最后ship给QA人工测试，如果发现bug，再补充

1. 单元测试

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

Answer 1

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

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

至于上面的流程大纲，我可能看错了。看来您正在削减单元测试以提高速度。即在没有 TDD 的情况下执行 ATDD。

如果那是你的方向，我看到以下风险

• 验收测试很复杂:它们会告诉您某些事情失败了 - 但无助于缺陷隔离。同一个验收测试可能因多种原因而失败/多个系统测试可能因同一个错误而失败。您可能会浪费很多时间来追查原因。集中的单元测试应该立即准确地告诉您问题出在哪里。随着时间的推移，调试验收测试失败所花费的时间可能会超过不编写重点测试所节省的时间
• 验收测试很慢:与单元测试相比，您只能在 5 分钟内运行少量(乐观的)大块测试。您可以同时运行数千个微测试。这很有用的原因是单元测试会给你更快的反馈，更接近破坏某些东西的代码更改。由于它们需要时间来运行，通常的趋势是运行验收测试的次数最少。花更多时间来确定导致应用程序崩溃的确切代码更改。
• 验收测试并不彻底:无法涵盖所有​​微小的边缘情况，因为它会导致不可行的测试套件执行时间。错误会在那些未经测试的地方滋生。

最后恕我直言，验收/系统测试应该是最后一道防线；不是第一个。我见过团队在代码质量问题上苦苦挣扎，团队对代码质量并不真诚，而是依靠系统测试来捕捉一切；如上所述，这是在自欺欺人。 TDD 对代码质量有更直接的影响。ATDD 只会告诉您某些东西坏了/客户“ Not Acceptable ”。也就是说，根据您团队中纪律和经验的正确组合，它可能会在短期内奏效……只是我不会打赌。

如果您想减少单元测试所花费的时间，请与团队坐下来定义关键/重点领域/模块。使用 TDD 完成这些任务。