C# - 原型(prototype)设计时的 TDD 策略

Question

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

在红色/绿色重构中，我从所有单元测试开始并失败(红色)。然后我执行我的代码，直到所有测试通过(绿色)。

例如，如果我有一个需要实现 10-20 倍的接口(interface)，那么我只需在一个类中实现该接口(interface)，该类将所有方法设置为抛出 NotImplementedException。然后，为每个公共(public)方法创建一个测试。从那里，我只需编写代码来修复测试。

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

在这种情况下，我正在编写一些垃圾软件。制作原型(prototype)只是为了弄清楚我的设计需要什么。 (也许我需要在这里传递一个文件名，也许传递给这个构造函数...)。

最终，我想保留 TDD。我确实相信它使我的代码保持最少并且 lean .

TDD 是否适用于原型(prototype)设计？换句话说，是否有一种方法可以让我在不完全确定我的设计方向时让 TDD 为我工作？

Answer 1

是的，但它像 API 一样。与其猜测如何用 excel 做某事，不如决定你想做什么作为最终结果。 (示例:读取单元格 A0 到 A100)

然后，当您了解它在该界面背后的工作方式时，您最终会看到您可以拆分并自行测试的内容，以及可能对设计更有效的内容。 (示例:编写代码以读取 0,0 到 0,100 并删除字母代码，因为它更复杂而没有任何好处)

不要害怕因设计/行为更改而导致测试无效，它们只是提供帮助，而不是具体的。 (示例:应删除读取单元格 A0 到 A100 的原始测试)