3、不知道怎么编写单元测试

    如果你相信单元测试的价值，那么去学习如何编写单元测试最终会让你获益的。 

    以Java开发为例，junit这样的单元测试组件是非常易于学习和使用的。其它语言也有类似的单元测试组件。要相信这将是简单和能为你带来价值的。笔者见过许多程序员编写单元测试，但是编写的单元测试完全没有起到它应有的作用，这也与不知道怎么编写单元测试有关。所以我们应该掌握一些编写单元测试的基本原则: 

    •为什么编写测试：虽然我们说为所有的代类都编写单元测试，但是测试JavaBean的setter或getter方法无异于是自寻烦恼。编写这样的测试完全是浪费时间，而且还增加了维护的困难。 

    •学会使用断言：断言就是让我们为方法设置一个期望值。当方法执行结果与期望值不一致时，测试组件就会报告测试不通过。我见过一些项目的单元测试不是使用断言，而是自己编写一个打印(println)工具类，可以详细的在控制台中打印出类的详细成员信息及集合的详细信息。 

    在单元测试中使用这个打印工具类来打印输出结果。这看起来好像非常不错。但是不应该使用这种方式来编写单元测试使用打印工具类，需要程序员自已从控制台去观察程序的执行结果。当输出信息非常多时，控制台信息是无法向上翻屏的。所以不能够给我们提供更多的信息。所以这种方法也不能用于自动化测试。 

    使用打印工具类造成了一种假像，测试报告我们的测试总是成功的！如果使用断言，当方法的执行结果与我们设置的期望值不一致时，则会详细的报告测试失败的情况。 

    使用打印工具来代替断言，造成测试的不充分，只会写出一个低测试覆盖率的测试。我们需要一个充分的测试。 

    •最大化测试覆盖率：我们除了测试一个正确的路径外，还需要测试方法的每一个分支逻辑。需要编写尽可能多的测试程序代码的测试。写一个充分的测试。 

    •避免重复的测试代码：测试类也是非常重要的，与应用代码一样。测试类包含的重复代码越多，测试类自身出现的错误也会越多。而我们需要做的编码工作也就越多。 

    • 不要依赖于测试方法的执行顺序：使用Junit来进行单元测试，它不能保证测试方法按照我们的意图的顺序来执行。当一个测试类有多个测试方法时，我们不能让一个测试方法必须在某一个测试之后执行才能成功。Junit不能为我们做这样的保证，我们不能依赖于测试方法的执行顺序。 

    •针对接口测试：我们有“针对接口编程”的OO设计原则。同样对于测试，我们也需要针对接口测试。也就是说在编写单元测试时，测试对象总是使用接口，而不是使用具体类。