我读了很多帖子,说服我应该开始编写单元测试,我也开始使用依赖注入(Unity)以便更容易进行模拟,但我仍然不太确定我应该在哪个阶段开始编写单元测试和模拟,以及如何或从何处开始.
首选方法是在TDD方法中描述的方法之前编写单元测试吗？
单元测试有什么不同的方法或方式吗？
Mar*_*son 32
先测试/测试后:
应该注意的是,作为TDD的一部分,"先测试"与设计一样多(如果不是更多)与单元测试有关.它本身就是一种软件开发技术 - 编写测试结果可以不断改进设计.
另请注意:如果从单元测试的角度来看TDD有一个显着优势,那就是在进行TDD时编写一个错误的测试要困难得多(尽管不是不可能).如果您事先编写测试,它应该总是失败,因为测试通过所需的逻辑尚不存在.如果你之后编写测试,逻辑应该在那里,但如果测试被窃听或测试错误的东西,它可能会通过.
也就是说,如果你以前写过一个不好的测试,当你期望红色时你可能会得到绿灯(所以你知道测试是坏的).如果你之后写了一个不好的测试,当你期望一个绿色(没有意识到不好的测试)时,你会得到一个绿灯.
图书
实用的单元测试书非常值得一看,Roy Osherove的"单元测试艺术"也是如此.实用主义书更侧重于您可以尝试查找错误的不同类型的测试输入,而TAOUT涵盖了更广泛的主题,如测试双打,策略,可维护性等.这两本书都很好; 这取决于你想要的东西.
此外,这里还有一个关于Roy Osherove谈论单元测试的链接.这值得观看(他记录的一些测试评论视频也是如此,因为他指出了各种问题和注意事项以及原因).
怎么开始
没有比编写代码更好的了.找一个相当简单的类,但没有引用其他内容.然后,开始编写一些测试.
总是问自己"我想尝试用这个测试来证明什么？" 在你编写之前,给它一个合适的名称(通常涉及被调用的方法,场景和预期结果,例如在堆栈上:"Pop WhenStackIsEmpty ThrowsException").
想想你可以投入的所有输入,可能产生有趣结果的不同方法组合等等.
Ty.*_*Ty. 14
如果您对单元测试感到好奇,那么最好的方法是尝试它.您可能会首先开始编写集成测试,但这很好.当它们看起来难以维护或编写太多工作时,请阅读更多关于有哪些类型的测试(单元,功能,集成)并尝试了解其中的差异.
如果你有兴趣从TDD开始,鲍勃叔叔是一个很好的来源.Particalulary this.
更多关于单元测试
确保您获得一致的测试结果.重复运行相同的测试应该始终如一地返回相同的结果.
测试不应该要求配置.
测试顺序无关紧要.这意味着部分测试运行可以正常工作.此外,如果您牢记这一设计理念,它可能有助于您的测试创建.
请记住,任何测试都比没有测试好.在编写良好的清洁单元测试时可以找到困难,这些测试可以简化创建和维护.测试框架越难,使用它就越反对.测试是你的朋友.
在C#和visual studio中,我发现以下过程非常有用:
认为!做一个小的前期设计.您需要清楚地了解您需要哪些类以及对象应如何相互关联.只关注一个类/对象(您要实现的类/对象)和一个关系.否则你最终会有一个太重量级的设计.我常常在一张备用的纸上画出多个草图(只有几个方框和箭头).
在生产代码中创建类并对其进行适当命名.
选择要实现的类的一种行为,并为其创建方法存根.使用visual studio创建空方法存根是件小事.
为它写一个测试.因此,您需要初始化该对象,调用该方法并生成一个断言来验证结果.在最简单的情况下,断言需要生产代码中的另一个方法存根或属性.
编译并让测试运行器显示红色条!
在生产代码中编码所需的行为以查看绿色条.
转到下一个行为.
对于这个过程,有两件事非常重要:
首先测试还是先测试？
我发现将测试改装到现有的生产代码通常更难.在大多数情况下,当需要初始化被测对象时,这是由于与其他对象的纠缠不清.TDD通常会避免这种情况,因为您希望尽可能少地在测试用例中初始化对象.这将导致非常松散的耦合.
当我改进测试时,必须繁琐的工作是初始化测试对象的任务.由于纠结的依赖性,断言也可能是很多工作.为此,您需要更改生产代码并破坏依赖关系.通过正确使用依赖注入,这应该不是问题.
是的,执行TDD 的首选方法是首先编写测试(正如名称Test-Driven Development所暗示的那样).当你开始使用TDD时,很难知道从哪里开始编写测试,所以我建议对它采取务实态度.毕竟,我们工作中最重要的部分是提供工作代码,而不是如何制作代码.
因此,您可以从为现有代码编写测试开始.一旦你了解了单元测试的结构,哪些看起来做得不错,哪些看起来不那么神,那么你会发现更容易深入了解测试优先的方法.我发现随着时间的推移,我首先在更大程度上编写测试.随着经验的增加,它变得更加自然.
史蒂夫桑德森有一篇关于TDD最佳实践的精彩文章.
http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/
此外,还有很多关于做ASP.net mvc项目的教程,讨论了很多TDD原则(如果你不介意沿途学习ASP.net MVC) http://www.asp.net/learn/ mvc-videos /在页面底部查找"店面"系列.
最近MOQ似乎是热门的模拟框架,你可能也想研究它
总之,尝试编写一个测试来验证您试图存档的内容,然后实现代码以使其工作.
这种模式被称为Red - Green - Refactor.还要尽力减少依赖关系,以便测试可以专注于一个组件.
就个人而言,我使用Visual Studio单元测试.我不是铁杆TDD开发者,但我喜欢做的是:
我也觉得在现有代码库中添加功能非常有用.如果要添加一些新功能,首先要为要添加的内容创建单元测试,逐步执行代码以查看必须更改的内容,然后再进行TDD过程.
选择一个小的非关键应用程序并使用TDD实现它.起初,新的思维方式会让人觉得奇怪,但也许经过一两个星期的练习后,感觉很自然.
这是一个教程应用程序(在分支"教程"中),它显示了要编写的测试类型.在该教程中,您编写代码以传递预定义的测试用例,以便您进入节奏,然后再编写自己的测试.README文件包含说明.它是用Java编写的,但您可以轻松地将其应用于C#.