|
7.JUnit最佳实践
Martin Fowler（又是这位高人）说过：“当你试图打印输出一些信息或调试一个表达式时，写一些测试代码来替代那些传统的方法。”一开始，你会发现你总是要创建一些新的Fixture，而且测试似乎使你的编程速度慢了下来。然而不久之后，你会发现你重复使用相同的Fixture，而且新的测试通常只涉及添加一个新的测试方法。
你可能会写许多测试代码，但你很快就会发现你设想出的测试只有一小部分是真正有用的。你所需要的测试是那些会失败的测试，即那些你认为不会失败的测试，或你认为应该失败却成功的测试。
我们前面提到过测试是一个不会中断的过程。一旦你有了一个测试，你就要一直确保其正常工作，以检验你所加入的新的工作代码。不要每隔几天或最后才运行测试，每天你都应该运行一下测试代码。这种投资很小，但可以确保你得到可以信赖的工作代码。你的返工率降低了，你会有更多的时间编写工作代码。
不要认为压力大，就不写测试代码。相反编写测试代码会使你的压力逐渐减轻，应为通过编写测试代码，你对类的行为有了确切的认识。你会更快地编写出有效率地工作代码。下面是一些具体的编写测试代码的技巧或较好的实践方法：
1. 不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台会按不同的顺序从Vector中取出测试方法。
3. 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的会滚就可以了。
4. 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。
5. 将测试代码和工作代码放在一起，一边同步编译和更新。（使用Ant中有支持junit的task.）
6. 测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。
7. 确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。
8. 如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。
9. 尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。
10.测试要尽可能地小，执行速度快。
事实上，JUnit还可用于集成测试，但我并没涉及到，原因有两个：一是因为没有单元测试，集成测试无从谈起。我们接受测试地概念已经很不容易了，如果再引入集成测试就会更困难。二是我比较懒，希望将集成测试的任务交给测试人员去做。在JUnit的网站上有一些相关的文章，有空大家可以翻一翻。
8.JUnit与J2EE
如果大家仔细考虑一下的话，就会发现，JUnit有自己的局限性，比如对图形界面的测试，对servlet/JSP以及EJB的测试我们都没有举相关的例子。实际上，JUnit对于GUI界面，servlet/JSP，JavaBean以及EJB都有办法测试。关于GUI的测试比较复杂，适合用一整篇文章来介绍。这里就不多说了。
前面我们所做的测试实际上有一个隐含的环境，JVM我们的类需要这个JVM来执行。而在J2EE框架中，servlet/JSP，EJB都要求有自己的运行环境：Web Container和EJB Container。所以，要想对servlet/JSP，EJB进行测试就需要将其部署在相应的Container中才能进行测试。由于EJB不涉及UI的问题（除非EJB操作XML数据，此时的测试代码比较难写，有可能需要你比较两棵DOM树是否含有相同的内容）只要部署上去之后就可以运行测试代码了。此时setUp()方法显得特别有用，你可以在setUp()方法中利用JNDI查找特定的EJB。而在testXXX()方法中调用并测试这些EJB的方法。
这里所指的JavaBean同样没有UI的问题，比如，我们用JavaBean来访问数据库，或用JavaBean来包裹EJB。如果这类JavaBean没有用到Container的提供的服务，则可直接进行测试，同我们前面所说的一般的类的测试方法一样。如果这类JavaBean用到了Container的提供的服务，则需要将其部署在Container中才能进行测试。方法与EJB类似。
对于servlet/JSP的测试则比较棘手，有人建议在测试代码中构造HttpRequest和HttpResponse，然后进行比较，这就要求开发人员对HTTP协议以及servlet/JSP的内部实现有比较深的认识。我认为这招不太现实。也有人提出使用HttpUnit。由于我对Cactus和HttpUnit 了解不多，所以无法做出合适的建议。希望各位先知们能不吝赐教(ericwq@263.net)。
正是由于JUnit的开放性和简单易行，才会引出这篇介绍文章。但技术总在不断地更新，而且我对测试并没有非常深入的理解；我可以将一个复杂的概念简化成一句非常容易理解的话。但我的本意只是希望能降低开发人员步入测试领域的门槛，而不是要修改或重新定义一些概念。这一点是特别要强调的。最后，如果有些兄弟姐妹能给我(ericwq@263.net)指出一些注意事项或我对某些问题的理解有误，我会非常感激的。
2001年冬雨（唉，已经下了10几天的雨了）上海
| 
