1、单体测试应该小并且快
理想情况下在每次代码签入之前都要执行下测试套件。测试快就可以降低开发周转时间。
2、单体测试必须完全自动化，不需要交互
测试套件通常经常执行，必须完全自动化才有用。如果结果需要人工检查，该测试就不是真正的单体测试。
3、单体测试应便于运行
开发环境应该配置成通过一个单独的命令或者一个按钮点击就可以运行单独的测试和测试套件。
4、评估测试
对测试的运行进行覆盖分析从而得到执行覆盖并调查代码的哪些部分执行，哪些部分没有执行。
5、立刻修复失败测试
每个开发者都应该确保在签入后新的测试以及所有既有的测试都可以成功运行。
如果在日常测试执行中有一个测试失败了，整个团队必须停下手头的工作来保证问题得到解决。
6、保持测试在单体层
单体测试和类的测试相关。每个普通类都要有一个测试类，类的行为应该在隔离的条件下测试。应该避免使用单体测试框架测试整个工作流程，因为这样的测试会很慢并很难维护。会有需要流程测试的地方，但不应该作为单体测试的一部分，它必须独立地设置和执行。
7、从简单开始
一个简单的测试要比根本没有测试好。一个简单的测试类可以建立起目标类的测试框架并可以验证编译环境、单体测试环境、执行环境和覆盖分析工具是否具备以及是否正确，从而可以证明目标类是否是程序集的一部分以及是否可以访问。
单体测试的入门程序可能像这样：
| void testDefaultConstruction() { Foo foo = new Foo(); assertNotNull(foo); } |
8、保存测试相互独立
为了确保测试健壮并简化维护，测试不能依赖其它测试以及测试执行的先后顺序。
9、测试类和被测试类尽量近
如果被测试类是Foo，那么测试类就应该命名为FooTest（而不是TestFoo）并同Foo放在同一个包里面。将测试类放在单独的目录下会使其难于访问和维护。
确保编译环境的配置可以使得测试类不会进入生产库或执行文件中。
10、合理命名测试
确保每个测试方法测试一个明显的类功能并据此命名测试方法。典型的命名规则是test[what]，比如testSaveAs()， testAddListener()， testDeleteProperty()等。
11、测试公开API
单体测试被定义为通过公开API测试类。有些测试工具可以实现类的私有方法的测试，但由于这会使得测试太过繁琐并更难于维护因此需要避免。如果有一些类的私有方法需要显示地进行测试，考虑将其重构成工具类的公开方法。要这样做就应该要改进总体设计，而不是仅仅为了帮助测试。
12、以黑盒考虑
作为第三方的类使用者来测试该类是否满足需求。尝试着让它失效。
