问：如果我很忙，能不能让别人代劳做单元测试？

　　答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。

　　最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

　　单元测试过后，机器状态保持不变。

　　这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段把这些临时的文件或目录删除。

　　如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。

　　单元测试要快（一个测试运行时间是几秒钟，而不是几分钟）。

　　快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试。

　　单元测试应该产生可重复、一致的结果。

　　如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

　　问：如果用随机数以增加测试的真实性，好么？

　　答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，于事无补。要注意我们还是要用随机数等办法“增加测试的真实性”，但是不是在单元测试中。单元测试不能解决所有问题，所以也不必期望它会发现所有的缺陷。

　　独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。

　　程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。

　　如果其他的模块很不稳定，或者其他模块运行比较费时（如进行网络操作），而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据以保证这个单元测试的独立性。

　　单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，单元测试必须测试公开的和私有的函数/方法。

　　单元测试必须覆盖所测单元的所有代码路径。

　　问：啊！这样岂不是要写很多啰里啰唆的测试方法？

　　答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉。

　　大栓：这对于那些爱写复杂代码的人是一个很好的惩罚，不对，是一个很好的锻炼。

　　阿超：对，把单元测试的责任和代码作者绑定在一起后，代码作者就能更真切地体会到复杂代码的副作用，因为验证复杂代码的正确性要困难得多。要注意的一点是：100%的代码覆盖率并不等同于100%的正确性。