1

尽管 TDD/BDD 是理想的并且由于时间有限，您不可能总是拥有 100% 的测试覆盖率并且总是在实现功能之前编写测试，那么，您有什么方法可以在紧迫的时间安排下拥有一个经过良好测试的项目？

我最初的想法是：

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

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

  1. 集成测试

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

  1. 单元测试

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

4

1 回答 1

6

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

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

至于上面的流程大纲，我可能读错了。看来您正在削减单元测试以提高速度。即不使用TDD 进行ATDD。

如果那是您前进的方向，我会看到以下风险

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

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

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

于 2012-08-22T05:22:03.210 回答