程序员为什么不写单元测试
发布: 2009-2-17 13:44 | 作者: 不详 | 来源: 领测软件测试网采编 | 查看: 2次 | 进入领测软件测试网论坛讨论
3、不知道怎么编写单元测试
如果你相信单元测试的价值，那么去学习如何编写单元测试最终会让你获益的。
以Java开发为例，junit这样的单元测试组件是非常易于学习和使用的。其它语言也有类似的单元测试组件。要相信这将是简单和能为你带来价值的。笔者见过许多程序员编写单元测试，但是编写的单元测试完全没有起到它应有的作用，这也与不知道怎么编写单元测试有关。所以我们应该掌握一些编写单元测试的基本原则:
•为什么编写测试：虽然我们说为所有的代类都编写单元测试，但是测试JavaBean的setter或getter方法无异于是自寻烦恼。编写这样的测试完全是浪费时间，而且还增加了维护的困难。
•学会使用断言：断言就是让我们为方法设置一个期望值。当方法执行结果与期望值不一致时，测试组件就会报告测试不通过。我见过一些项目的单元测试不是使用断言，而是自己编写一个打印(println)工具类，可以详细的在控制台中打印出类的详细成员信息及集合的详细信息。
在单元测试中使用这个打印工具类来打印输出结果。这看起来好像非常不错。但是不应该使用这种方式来编写单元测试使用打印工具类，需要程序员自已从控制台去观察程序的执行结果。当输出信息非常多时，控制台信息是无法向上翻屏的。所以不能够给我们提供更多的信息。所以这种方法也不能用于自动化测试。
使用打印工具类造成了一种假像，测试报告我们的测试总是成功的！如果使用断言，当方法的执行结果与我们设置的期望值不一致时，则会详细的报告测试失败的情况。
使用打印工具来代替断言，造成测试的不充分，只会写出一个低测试覆盖率的测试。我们需要一个充分的测试。
•最大化测试覆盖率：我们除了测试一个正确的路径外，还需要测试方法的每一个分支逻辑。需要编写尽可能多的测试程序代码的测试。写一个充分的测试。
•避免重复的测试代码：测试类也是非常重要的，与应用代码一样。测试类包含的重复代码越多，测试类自身出现的错误也会越多。而我们需要做的编码工作也就越多。