如果我的项目变化很快，我应该使用 TDD 和 BDD 吗？ [关闭]答案

【问题标题】：Should I use TDD and BDD if my project is changing fast? [closed]如果我的项目变化很快，我应该使用 TDD 和 BDD 吗？ [关闭]
【发布时间】：2013-03-15 23:07:15
【问题描述】：

我有自己的小项目，我正在使用 RoR 创建，我计划它具有中小型负载。
毫无疑问，我从 BDD 和 TDD（确切地说是 Cucumber 和 RSpec，但我对 TestUnit 也有经验）开始，我喜欢它，但因为它是我自己的项目，而且它有点初创 - 我正在改变其中的很多东西，很多要求，许多想法应该如何工作和看起来。因此，总是使用 BDD 和 TDD 对其进行编码变得非常耗时，即使我只介绍了常见情况。
我该怎么办？我是否应该牺牲 BDD 和 TDD 来提高生产力，直到我有一个坚实的基础并且是时候进行生产，然后再编写测试？
我应该现在就写它们，但尽可能少吗？我现在应该只写 RSpec 而忘记 Cucumber 吗？或者也许现在只是 TestUnit 来测试模型，因为它是最重要的，其他一切都可以改变？
提前致谢！

【问题讨论】：

这是团队合作还是一个人的项目？
这似乎违反直觉，但我发现拥有一个好的测试套件可以帮助我快速改变

标签： ruby-on-rails unit-testing tdd integration-testing bdd

【解决方案1】：

这不是一个政治正确的答案，我相信它会让纯粹主义者感到不安。这里是这样：对于一个小型、快速变化的项目，最好只编写代码并跳过 TDD 和 BDD 步骤。否则，您将大大延迟完成。这不是应该始终遵循的规则，但如果您认为您了解项目的要求，那么不要对编写代码感到内疚。

【讨论】：

【解决方案2】：

使用 BDD/TDD 可能会提高您的工作效率。您说您的需求经常变化，也许改变/编写测试用例等比编写实际代码然后销毁它并在每次需求变化时编写新代码更灵活/快速。也许这样做可以作为一种过滤器/层，通过它来审查您想要创建的更改。在您花时间实施之前，它可能会帮助您了解事情是否会奏效。当您实施它时，您当然会获得 TDD 的好处，您将拥有测试套件来确保正确性。

【讨论】：

【解决方案3】：

就个人而言，如果我迭代只是来定义功能、设计、实现等。我倾向于轻描淡写地进行测试。

也就是说，一旦我完成该部分，我通常会抛开那些开发高峰，并使用 T/BDD 推进可交付成果。

【讨论】：

【解决方案4】：

在我看来，既然这是你的项目，那么你就真的坐在驾驶座上。如果您觉得 TDD/BDD 的优势比更多实验/更快上市时间的优势强，那么我会说坚持下去。另一方面，如果你真的要确定项目是否有腿，它可能最终会被废弃，那么在短期内专注于更快的学习可能是一个更好的选择。我想这就是我建议您确定项目当前目标并将您的实践与这些目标保持一致的方式。

虽然这并没有给出一个非常具体的答案，但我觉得有点像，但您可以进行一些更高级别的场景测试，以确保您不会破坏您的快速功能中的任何主要内容更改，但放弃 TDD/BDD 的全部内容。我个人的经验是，在练习 TDD 时我感觉更有效率，因为它帮助我一次专注于解决一个问题，而且我发现自己进入了一个更好的节奏。

希望有帮助！

布兰登

【讨论】：

嗯，我们的答案有相似之处。倾向于同意你的看法。 +1（也适用于甜蜜的头像：p）

【解决方案5】：

因此，总是使用 BDD 和 TDD 对其进行编码变得非常耗时，即使我只介绍了常见情况。

我似乎总是使用 TDD 来提高编码速度。在执行测试时找到“愚蠢的编码错误”，并比没有单元测试的情况下更快地找到根本原因。

对于 BDD，如果您的需求倾向于大修，我可以想象您会延迟需求测试，直到船舶朝着更统一的方向启航。

【讨论】：

【解决方案6】：

我认为您想使用 TDD（也许不是 BDD）正是因为需求变化如此之大。 TDD 支持可重构的设计 + 代码库，因此易于更改。在一个项目的过程中（即使是小到一两周），使用 TDD + 重构实际上会比不使用它更快。

【讨论】：