开始TDD - 挑战？解决方案？建议？

Question

好吧,我知道已经有关于开始使用TDD的问题了.但是,我想我知道一般的共识就是这样做,但是,我似乎有以下问题让我的头脑进入游戏:

使用集合时,仍然会测试显而易见的添加/删除/插入是否成功,即使基于泛型等我们"知道"它的工作方式？
有些测试似乎需要永远实现..比如在使用字符串输出时,是否有一种"更好"的方法来处理这类事情？(例如,在解析之前测试对象模型,将解析分解为小操作并在那里进行测试)在我看来,你应该总是测试"最终结果",但是这可能会变化很大并且设置起来很乏味.
我没有使用测试框架(工作不会支付一个)所以我可以"练习"更多.有没有免费商用的好产品？(目前我使用的是'ol Debug.Assert :)
可能是最大的..有时候我不知道会发生什么不发生..我的意思是,你得到了绿灯但是我总是担心我可能会错过一个测试..你是否深入挖掘试图打破代码,或者让它等待它以后都会掉下来(这将花费更多)..

所以基本上我在这里寻找的不是" 只是做它 "而是" 我做了这个,有这个问题,通过这个解决了它们 ".. 个人经历:)

Answer 1

首先,当您第一次开始尝试在编码风格中使用TDD时,感到沮丧是正常和正常的.只是不要气馁和退出,你需要给它一些时间.这是我们如何考虑解决代码中的问题的主要范式转变.我喜欢把它想象成当我们从程序化编程转向面向对象编程时.

其次,我认为测试驱动开发首先是一个设计活动,用于通过创建一个首先描述它将要公开的API以及如何使用它的功能的测试来充实组件的设计.该测试将有助于塑造和塑造被测系统,直到您能够封装足够的功能来满足您正在进行的任何任务.

考虑到上面的段落,让我们看看你的问题:

如果我在我的系统中使用集合,那么我将设置一个期望,以确保调用代码插入项目然后断言集合的计数.我不一定在我的内部列表上测试Add方法.我只是确保在调用添加项的方法时调用它.我通过在我的测试框架中添加一个模拟框架来实现这一点.
测试字符串作为输出可能很乏味.你无法解释每一个结果.您只能根据被测系统的功能测试您的期望.您应该始终将测试分解为它正在测试的最小元素.这意味着你将进行大量的测试,但测试虽然小而快,只能测试它们应该做什么,没有别的.
有很多开源测试框架可供选择.我不打算争辩哪个是最好的.找到你喜欢的并开始使用它.
您所能做的就是设置测试以说明您想要发生的事情.如果出现导致您的功能出现错误的情况,至少您需要测试该方案添加到测试中的功能,然后更改您的功能直到测试通过.找到我们可能错过测试的一种方法是使用代码覆盖.

我在第一个问题的答案中向你介绍了嘲弄术语.当你为你的TDD武器库引入模拟时,它会极大地使测试更容易抽象出不属于被测系统的部分.以下是有关模拟框架的一些资源:

除了阅读过程之外,帮助使用TDD的一种方法是观察人们这样做.我建议观看JP Boodhoo在DNRTV上播放的屏幕.看看这些:

好的,这些将帮助您了解我引入的术语是如何使用的.它还将引入另一个名为Resharper的工具以及它如何促进TDD过程.在做TDD时我不能推荐这个工具.好像您正在学习这个过程,而您只是找到了使用其他工具已经解决的一些问题.

如果我没有通过添加Kent Beck 关于实用程序员的测试驱动开发的新系列来更新它,我想我会对社区做一个不公正的事情.

Answer 2

根据我自己的经验:

只测试自己的代码,而不是底层框架的代码.因此,如果您使用通用列表,则无需测试添加,删除等.
没有2.看那边!猴子!
NUnit是要走的路.
你绝对无法测试每一个结果.我测试了我期望发生的事情,然后测试一些我希望得到异常或无效响应的边缘情况.如果因为你忘记测试的东西而在轨道上出现错误,那么你应该做的第一件事(在尝试修复bug之前)就是编写一个测试来证明bug存在.