单元测试是保证代码质量最基本的手段，但是现在的开发中却对单元测试不够重视。有的人认为编译器就是我们的代码质量保证，还有的人认为正确的调试就是测试，还有的人认为使用这个软件就是测试，这样的认识都是存在问题的。下面讲讲怎么样的单元测试才是好的单元测试。
单元测试应该准确、快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：
一、 单元测试应该在最低的功能/参数上验证程序的正确性；
单元测试应该测试程序中最基本的单元——如C#中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。
二、 单元测试必须由最熟悉代码的人（程序的作者）来写；
代码的作者最了解代码的目的、特点和实现的局限性。所以没有比作者更合适的人选。
就算作者没有时间写测试代码，也应该对此单元测试进行负责。
三、 单元测试过后，机器状态保持不变；
如果单元测试创建了临时的文件或者目录，在数据库中创建或修改了记录，都要删除临时数据。保证单元测试可以重复快速进行；
四、 单元测试要快（一个测试运行时间是几秒钟，而不是几分钟）；
快，才能保证效率。一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上要求一个类的测试在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中进行分类，分类进行测试。比如我只修改了“用户界面”的代码，我只需要运行“用户界面”的单元测试。
五、 单元测试应该产生可重复，一致的结果；
如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。一般情况下不要使用随机数以增加测试的真实性。
六、 独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据以保持单元测试的独立性；
程序中的各个模块都是相互依赖的，一般情况下，单元测试中的模块可以直接引用其它的模块，并期待其它的模块能返回正确的结果。如果其它模块很不稳定、未完成，或者运行比较费时，这是可以人为地构造数据以保证这个单元测试的独立性。
七、 单元测试应该覆盖所有的代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，单元测试必须测试公开的和私有的函数/方法；
如果你的模块中某个错误处理路径很难到达，那你要想想是否可以把这个错误处理拿掉。要注意一点：100%的代码覆盖率并不等同于100%的正确性。
八、 单元测试应该集成到自动测试的框架中；
一个重要的措施是要把测试自动化，这样每个人都能很容易地运行单元测试。团队一般在每日构建（在敏捷开发中要求每天都能够提供一个可以运行的版本进行构建）中运行单元测试，这样每个单元测试的错误就能及时发现并得到修改。
九、 单元测试必须和产品代码一起保存和维护。
单元测试必须和代码一起进行版本维护。如果不是这样，过一阵代码和单元测试就会出现不一致，而且所有代码的作者要花时间来确认那些是程序出现的错误，那些是由于单元测试更新滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试是一件很费时费力的事。
以上就是提到的单元测试好的建议，当然并不全面。希望能够得到大家的讨论和学习。
最后申明一下，上面的所有内容全部出自于《移山之道—VSTS软件开发指南》一书，如果大家对更多的内容感兴趣，可以去看看。