单元测试小技巧

　　这篇文章描述了：

　　单元测试的信任

　　测试正确事件

　　创建维护测试

　　创建易读测试

　　这些天有很多的关于单元测试的和在不同的场景下为他们的应用程序编写单元测试(起始于, 我们2005年六月的 MSDN?Magazine 中有关测试你的数据层的文章, Know Thy Code: Simplify Data Layer Unit Testing using Enterprise Services)的讨论。这些意味着有很多的开发者自言自语(或者对于他们的团队)到：“哎，我们也需要开始编写测试了!”因此他们开始编写单元测试上面的单元测试直到他们达到了一个测试自己已经成为问题的程度。或许维护他们是一个太过困难，花费太长时间，或者他们并没有足够的易读性以便于理解，更或者他们本身存在bugs有一点是能够使得我们的开发人员可以下定决心去做的，那就是： 花费他们宝贵的时间以用来改进提高他们的测试或者忽略其中的问题, 从而有效的甩掉那些艰苦的工作。而这些困难的原因仅仅是因为那些不熟练的写入单元测试。.在这篇文章中，我将为大家带来在过去一年多时间里我在开发，提供咨询和培训开发者等方面有总结出来的一些最重要的练习和试验。这些小的技巧可以帮助您写出更有效的，可维护，和鲁棒性更好的单元测试。同时我希望这些总结和忠告可以帮助您避免一些由于错误引起的大量的时间的消耗。

　　本页内容

　　单元测试的信任

　　测试正确的事情

　　创建维护测试

　　创建易读性测试

　　在你的设置方法中避免部分相关的代码

　　总结

　　单元测试的信任

　　在这个部分，我将略述出一些最通用的信任，这些信任来自于在使用大量单元测试获得的好处和解释为什么这些信任通常不是必须真实的。然后我们会帮助您在您的工程中拥有这些信任。

　　更加简单的跟踪Bug 当然这并不是必须的，那么您怎么知道您的测试是正确的? 是否存在在一些测试环节测试失败的情况?另外您又如何知道您的测试覆盖了系统中多少的代码量?是否测试到了程序中的错误，错误又在哪里等等的问题。

　　当你在你的单元测试中发现了bug后又会发生什么事情哪?你会突然间得到很多与愿意错误的反馈，bug 被发现，但是问题并不在你测试的代码中。你的测试的逻辑存在一个bug，因此测试失败了。这些bug也是您最难被检查出来的，因为您通常会去检查您的应用程序而不会去检测你的测试环节。在这部分中，我会展示给你如何确认大量的单元测试，事实上就是使得跟踪bug变得更加容易。

　　代码更加便于维护 从最终点考虑，你可以倾向于认为这些信任并不是必须的，当然你是对的，让我们去说，代码中每个逻辑方法至少要有一个测试方法(当然，你可能拥有一个以上的方法)在一个好的测试覆盖的工程中，大概有百分之六十的代码是能够得到单元测试的，现在不得不考虑到测试也是要被维护的，如果针对一个复杂的逻辑方法你有 20个测试，那么当你向这个方法添加一个参数时会发生什么事情哪?测试无法编译。当你修改了类的结构的时候同样会发生这样的事情。这时你突然发现为了能让你的应用程序继续工作你自己需要改变大量的测试。当然这会花费你大量的时间。

　　为了使这个信任确认下来，你需要确认你的测试是便于维护的。保持DRY规则写入：不要重复你自己。我们将更加接近的来看这个问题。

　　代码更加容易被理解 单元测试的好处通常并非是人们最初所期待的，在一个工程中考虑修改一些你之前从没有看过的代码(比方说,一个特殊的类或者方法).你将如何动手处理这些代码?你可能需要在项目中去浏览这些特定的类或者方法使用的代码，理所当然，单元测试就是这样例子的一个很好的场所。同时，当正确写入的时候，单元测试可以为工程提供一个API文件的容易读取的设置，使得文档的处理和代码的理解对于整个团队中的新老开发者一样的简单，便捷。然而，这些只能在测试是易读的和容易理解的情况下才能被确认，这个规则很多的单元测试开发者并不会遵循。我将详述这个信任，然后在这篇文章的易读测试的部分给你展现如何在去写易读的单元测试。

　　返回页首

　　测试正确的事情

　　新来者在Test Driven Development (TDD)中一个最通常的错误就是他们通常会搞混"Fail by testing something illogical."中的"Fail first"要求。例如，你可以用下面的规格开始这个方法：

原文转自：http://www.uml.org.cn/Test/200605091.htm