需求不明确的测试驱动程序

Question

我知道TDD有很多帮助，我喜欢这种开发方法，当你首先创建一个测试，然后实现功能。这是一条非常清晰和正确的道路。

但是，由于我的项目的一些特点，当我开始开发一些模块时，我几乎不知道我想要什么，以及它最终会是什么样子。需求出现在我开发时，当我删除全部或部分旧代码并编写新代码时，可能会有2到3次迭代。

我看到两个问题: 1。我想尽快看到结果，了解我的想法是对还是错。单元测试会减慢这个过程。因此，我经常在代码完成后编写单元测试，这被认为是一个糟糕的模式。2.如果我首先编写测试，我不仅需要重写代码两次或更多次，还需要重写测试。这需要很多时间。

请问在这种情况下，如何应用TDD呢？

提前感谢！

Answer 1

我想尽快看到结果，了解我的想法是对还是错。单元测试会减慢这个过程。

我不同意。单元测试和TDD通常可以加快获得结果的速度，因为它们迫使您专注于结果，而不是实现大量您可能永远不需要的代码。它还允许您在编写代码时运行代码的不同部分，这样您就可以不断地看到您得到的结果，而不必等到整个程序完成。

Answer 2

我发现TDD在这种情况下工作得特别好；事实上，我想说的是，需求不明确和/或更改实际上是很常见的。

我发现TDD的最佳用途是确保您的代码正在执行您期望它执行的操作。当你写任何代码的时候，你应该知道你想要它做什么，不管需求是否清晰。TDD在这里的优势在于，如果需求发生变化，您可以简单地更改一个或多个单元测试以反映更改后的需求，然后更新代码，同时确保不会破坏其他(未更改)功能。

我认为，有一件事让很多测试开发人员感到困惑，那就是假设所有的测试都需要提前编写。我认为使用经验法则更有效，即当所有测试都通过时，您永远不要编写任何实现代码；这只是确保覆盖所有代码，同时还确保您检查所有代码是否完成了您希望它做的事情，而不必担心预先编写所有测试。

Answer 3

你的主要问题是当你不得不删除一些代码的时候。这是waste，这是应该首先解决的问题。

也许你可以原型化，或者利用“尖峰解决方案”来验证需求和你的想法，然后在真正的代码上应用TDD，一旦需求是稳定的。

风险在于应用这一点，并不得不交付原型。

你也可以先试驾“阳光之路”，然后再实现其他的，比如错误处理……在需求被固定下来之后。然而，实施的第二阶段将不那么有动力。

您使用的是什么开发流程？这听起来很敏捷，因为你正在进行迭代，但不是在一个完全支持它的环境中。