我发现某些形式的编写代码比其他代码更适合TDD。特别是红绿色重构测试。
在Red / Green重构器中，我从所有单元测试开始并且失败（红色）。然后我实现我的代码，直到所有测试通过（绿色）。
例如，如果我有一个需要实现10-20x的接口，那么我只需在类中实现接口，该接口将所有方法设置为抛出NotImplementedException。然后，为每个公共方法创建一个测试。从那里，我只是编写代码来修复测试。
流程并非总是如此直截了当。例如，我正在编写一个基本的Excel解析器。我不熟悉Excel Interop API。我发现简单地编写代码更容易。然后，通过反复试验，我发现了我的班级设计。
在这种情况下，我正在编写一些垃圾软件。原型设计只是为了弄清楚我的设计需要做什么。 （也许我需要在这里传入一个fileName，也许这个构造函数...）。
最终，我想保留TDD。我相信这会使我的代码保持最小化lean。
TDD是否适用于原型设计？换句话说，是否有一种我可以遵循的方法，以便TDD能够为我工作，即使我不完全确定我的设计在哪里？
答案 0 :(得分：2)
是的，但是就像API一样。而不是猜测如何用excel做某事，决定你想做什么作为最终结果。 （示例：读取单元格A0到A100）
然后，当你继续讨论它在该界面背后的工作方式时，你最终会看到它可以自行断开和测试的内容，以及可能对设计更有效的方法。 （示例：编写代码读取0,0到0,100并删除字母代码，因为它更复杂而没有任何增益）
不要害怕因设计/行为变化导致的测试无效，它们可以提供帮助，而不是具体的。 （示例：应删除读取单元格A0到A100的原始测试）
答案 1 :(得分：0)
恕我直言，你会有几个选择：
非常确定人们有更多的建议，但这些是我最喜欢的两种方法