4、我需要做什么

　　其实惹人的单元测试是很简单的，因为它自己布满了乐趣。然而在项目交付的时候，我们给客户和终用户的仍然是产物代码，而不包含单元测试的代码；所有，我们必需对单元测试的目的有个充实的熟悉。首先也是主要的，使用单元测试是为了使你的工作??以及你队友的工作??完成得加倍轻松。

　　● 它的行为和我的期望一致吗？

　　根柢的，你需要回覆下面这个问题：“这段代码达到我的目的了吗？”也许代码所做的是错误的工作，但那是另外的问题了。你要的是代码向你证实它所做的是你所期望的。

　　● 它的行为一向和我的期望一致吗？

　　很多开发者说他们只编写一个测试。也是让所有代码从头至尾跑一次，只测试代码的一条正确执行路径，只要这样走一遍下来没有问题，测试也算是完成了。

　　可是，现实当然不会这么事事顺心，工作也不老是那么顺利：代码会抛出异常，硬盘会没有残剩空间，收集会失踪线，缓冲区会溢出等??而我们写的代码也会呈现bug。这是软件开发的“工程”部门。“工程”而言，土木匠工程师在设计一座桥梁的时候，必需考虑桥梁的负载、强风的影响、地震、洪水等等。电子工程师要考虑频率漂移、电压尖峰、噪音，甚至这些同时呈现时所带来的问题。

　　你不能这样来测试一座桥梁：在风和日丽的某，仅让一辆车顺遂地开过这座桥。显然，这种测试对于桥梁测试来说是远远不够的。相似地，在测试某段代码的行为是否和你的期望一致时，你需要确认：在任何情形下，这段代码是否都和你的期望一致；譬如在参数很可疑、硬盘没有残剩空间、收集失踪线等的时候。

　　● 我可以依靠单元测试吗？

　　不能依靠的代码是没有多大用处的。但更糟糕的是，那些你自认为可以相信的代码（可是结果证实这些代码是有bug 的）有时候也会让你花很多时间在跟踪和调试上。显然，几乎没有项目可以许可你在这上面花费太多的时间，是以无论如何，你都要避免这种“前进一步，萎缩后退两步”的开发体例。也是说，要闪开开发过程连结不变的轨范前进。

　　没人能够写出十全十美的代码；可是这并没有关系??只要你知道问题的地址足够了。很多类型软件项目的失败，诸如只能把坏了的太空船搁浅在遥远的行星，或者在翱翔的途中爆炸了，都能经由过程确认的限制来避免。例如，Arianne 5 号火箭软件重用了来自于之前一个火箭项目的一个程序库，而这个程序库并不能措置新火箭的翱翔高度（比原本火箭要高），从而在起飞40 秒之后发生了爆炸，导致5 亿美元的损失踪。

　　显然，我们但愿能够依靠于所编写的代码，而且清楚地知道这些代码的功能和约束。

　　例如，假设你写了一个反转数值序列的体例。在测试的过程中，你也许会传一个空序列给这个程序??但导致了程序解体。现实上，轨范并没有要求该轨范必需能够领受一个空序列，是以你可以只在体例的注释中声名这个约束：如不美观传递一个空序列给这个体例，那么这个体例将会抛出一个异常。此刻你马上知道了该代码的约束，年夜而也不需要用其他很麻烦的体例来解决这个问题（因为在某些地址要解决这个问题并未便利，好比在高空年夜气层中）。

　　● 单元测试声名我的意图了吗？

　　对于单元测试而言，一个让人欢快的意外收成是它能够辅佐你充实理解代码的用法。简单而言，单元测试像是能执行的文档，了然在你用各类前提挪用代码时，你所能期望这段代码完成的功能。

　　项目成员能够经由过程查看单元测试来找到如何使用你所写代码的例子。如果他偶然发现了一个你没有考虑到的测试用例，那么他也可以很快地知道这个事实：你的代码可能并不支持这个用例。

　　显然，在正确性方面，可执行的文档有它的优势。与通俗的文档分歧的是，单元测试不会呈现与代码纷歧导致的情形（当然，除非程序选择不运行这些测试）。

　　5、如何进行单元测试

　　单元测试原本是一项简单易学的手艺；可是如果能够遵循一些指导性原则（guideline）和根基规范，那么进修将会变得加倍轻易和有用。

　　首先要考虑的是在编写这些测试用例之前，如何测试那些可疑的用例。有了这样一个概略的想法之后，你将可以在编写实现代码的时候，或者之前，编写测试代码。

　　下一步，你需要运行测试用例，或者同时运行系统的所有其他测试，甚至运行整个系统的测试，前提是这些测试运行起来相对斗劲快。在此，我们要确保所有的测试都能够经由过程，而不只是新写的测试能够经由过程；这一点长短常主要的。也是说，在保证不惹人直接bug 的同时，你也要保证不会给其他的测试带来破损。

　　在这个测试过程中，我们需要确认这个测试事实是经由过程了还是失败了??但这并不意味着你或者其他晦气的人需要查看每个输出，然后才抉择这些代码是正确的还是错误的。

　　在此，你慢慢地会养成一个习惯：只要进行一次单元测试查看一下测试结果，可以马上知道所有代码是否都是正确的，或者哪些代码是有问题的。关于这个问题，我们将留在讨论如何使用单元测试框架时来具体讨论。