IDC资讯中心
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几天的雨了）上海
