C# - 原型设计时的 TDD 策略
我发现某些形式的代码编写方式比其他形式更适合 TDD。特别是红绿重构测试。
在红/绿重构中，我从所有单元测试就位开始，但失败了（红色）。然后我实现我的代码，直到所有测试通过（绿色）。
例如，如果我有一个需要实现 10-20 倍的接口，那么我只需在类中实现该接口，该类将所有方法设置为抛出 NotImplementedException。然后，为每个公共方法创建一个测试。从那里，我只需编写代码来修复测试。
流程并不总是那么简单。例如，我正在编写一个基本的 Excel 解析器。我不熟悉 Excel Interop API。我发现简单地编写代码更容易。然后，通过反复试验，我发现了我的班级设计。
在这种情况下，我正在编写一些垃圾软件。制作原型只是为了弄清楚我的设计需要是什么。 （也许我需要在这里传递一个文件名，也许传递给这个构造函数......）。
最终，我想保留 TDD。我确实相信它可以使我的代码保持最少并且精益。
TDD 适用于原型设计吗？换句话说，是否有一种我可以遵循的方法，以便即使我不完全确定我的设计将走向何方，TDD 也能为我工作？
I find that some forms of writing code lend themselves better to TDD than others. Especially, red-green refactor testing.
In Red/Green refactor, I start with all my unit tests in place and failing (red). Then I implement my code until all test pass (green).
For example, if I have an interface that needs to be implemented 10-20x then I simply implement the interface in a class, which sets all methods to throw NotImplementedException. Then, create a test for each public method. From there, I just write the code to fix the tests.
Processes aren't always so straight forward. For example, I'm writing a basic Excel parser. I'm not familiar with the Excel Interop API. I find it easier to simply write code. Then, through trial and error I discover my class design.
In this case I am writing some junk software. Prototyping it out just so I can figure out what my design needs to be. (Maybe I need to pass in a fileName here, maybe to this constructor...).
Ultimately, I would like to keep TDD. I do believe it keeps my code minimal and lean.
Does TDD work for prototyping? In other words, is there an approach I can follow so as to allow TDD to work for me even when I am not entirely sure where my design is going?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，但要像 API 一样进行。不要猜测如何使用 Excel 做某事，而是决定您想要做什么作为最终结果。 （示例：读取单元格 A0 到 A100）
然后，当您了解它在该界面后面如何工作时，您最终会看到您可以分解并自行测试什么，以及可能什么可能更适合设计。 （例如：编写代码来读取 0,0 到 0,100 并删除字母代码，因为它更复杂，没有任何增益）
不要害怕由于设计/行为更改而导致测试无效，它们是为了提供帮助，而不是具体的。 （示例：读取单元格 A0 到 A100 的原始测试应删除）
Yes, but do it like an API. Instead of guessing how to do something with excel, decide what you want to do as an end result. (Example: Read Cells A0 to A100)
Then as you go along with how it will work behind that interface, you will end up seeing what it is you can break off and test by itself, and possibly what might work better for the design. (Example: write code to read 0,0 to 0,100 and remove the letter code as it is more complex without any gain)
Don't be afraid of invalidating tests due to design/behavior changes, they are there to help, not be concrete. (Example: That original test to read cells A0 to A100 should be deleted)
恕我直言，您将有几个选择：
界面。然后您可以使用该接口创建 Mock 对象
(http://code.google.com/p/moq/)
很确定人们有更多的建议，但这是我的两个最喜欢的方法
IMHO you would have a couple of options:
interface. You can then use the interface to create a Mock object
(http://code.google.com/p/moq/)
pretty sure people have much more suggestions but these are two of my favorite approaches