我发现某些编写代码的形式比其他形式更适合 TDD。特别是红绿重构测试。
在 Red/Green 重构中，我从所有单元测试开始，然后失败(红色)。然后我实现我的代码，直到所有测试通过(绿色)。
例如，如果我有一个需要实现 10-20x 的接口(interface)，那么我只需在一个类中实现该接口(interface)，该类将所有方法设置为 throw NotImplementedException 。然后，为每个公共(public)方法创建一个测试。从那里，我只是编写代码来修复测试。
流程并不总是那么简单。例如，我正在编写一个基本的 Excel 解析器。我不熟悉 Excel Interop API。我发现简单地编写代码更容易。然后，通过反复试验，我发现了我的类设计。
在这种情况下，我正在编写一些垃圾软件。制作原型(prototype)只是为了弄清楚我的设计需要是什么。 (也许我需要在这里传递一个文件名，也许传递给这个构造函数......)。
最终，我想保留 TDD。我相信它使我的代码最小化和 lean 。
TDD 是否适用于原型(prototype)设计？换句话说，有没有一种我可以遵循的方法，即使我不完全确定我的设计要去哪里，也可以让 TDD 为我工作？
最佳答案
是的，但要像 API 那样做。与其猜测如何用 excel 做某事，不如决定你想做什么作为最终结果。 (示例:读取单元格 A0 到 A100)
然后，当您了解它在该界面背后的工作方式时，您最终会看到它是什么，您可以自行中断和测试，以及可能对设计更有效的东西。 (例如:编写代码读取 0,0 到 0,100 并删除字母代码，因为它更复杂，没有任何增益)
不要害怕由于设计/行为变化而使测试无效，它们是为了提供帮助，而不是具体的。 (例如:应该删除读取单元格 A0 到 A100 的原始测试)
关于C# - 原型(prototype)设计时的 TDD 策略，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7746517/