C# - 在原型设计时进行TDD的策略

Question

我发现编写代码的某些形式比其他形式更适合TDD，特别是红绿重构测试。

在红绿重构中，我首先准备好所有单元测试，并使其全部失败（红色）。然后实现代码，直到所有测试通过（绿色）。

例如，如果我需要实现一个接口10-20次，我只需在类中实现该接口，并将所有方法设置为抛出NotImplementedException。然后，为每个公共方法创建一个测试。从那里开始，我只需编写代码以解决测试问题。

但过程并不总是那么简单。例如，我正在编写一个基本的Excel解析器。我不熟悉Excel Interop API。我发现直接写代码更容易。然后通过试错法发现我的类设计。

在这种情况下，我正在编写一些垃圾软件，只是为了找出我的设计需要什么。（也许我需要在这里传递一个文件名，也许到这个构造函数...）。

最终，我希望保持TDD。我确信它可以使我的代码尽可能简洁和精益。

TDD是否适用于原型开发？换句话说，当我不确定我的设计方向时，有没有一种方法可以让TDD对我起作用？

- P.Brian.Mackey

---

针对您这种类型的问题，我认为您应该采用BDD而不是TDD来解决。http://en.wikipedia.org/wiki/Behavior_Driven_Development - Druegor

掌握技巧的重要一环是知道何时应用它。学习技巧时，将其应用于各种问题非常有价值，这样可以获得经验。然而，一旦你获得了那些经验，就可以评估任何给定的问题是否适合使用你掌握的技巧。如果你发现使用TDD进行原型设计不太有效率，那么就没有必要在该情况下使用它。 - Dan Bryant

首先声明一下，我个人并未在TDD中找到价值。然而，我对“TDD”原则的理解是：你编写一个失败的测试，然后只编写足够使其通过的代码。而你所采用的方式是编写所有测试用例，然后编写代码使它们全部通过。我不确定这种方式对推动你的设计会有多大帮助。 - tsells

Answer 1

是的，但要像API一样做。不要猜测如何使用Excel，而是决定想要实现的最终结果。（例如：读取单元格A0到A100）

随着您在接口背后工作的进展，您将看到可以分离并单独测试的内容，可能会更适合设计。（例如：编写代码以读取0,0到0,100并删除字母代码，因为没有任何收益而更复杂）

不要害怕由于设计/行为变化而使测试无效，它们是帮助而非具体的。（例如：应删除读取单元格A0到A100的原始测试）

- Rangoric

Answer 2

在我看来，您有几个选择：

• 分离关注点并将复杂的行为抽象成接口。然后，您可以使用接口创建模拟对象（http://code.google.com/p/moq/）。
• 使用 Pex 和 Moles 创建您的 Excel API 的 Mole（再次关注代码的分离和隔离），并在单元测试中使用 Mole 而不是真实的 API。

我相信人们有更多建议，但这些是我最喜欢的两种方法。

- Didier Caron