3. 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的会滚就可以了。
4. 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。
5. 将测试代码和工作代码放在一起，一边同步编译和更新。(使用Ant中有支持junit的task.)
6. 测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。
7. 确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。
8. 如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。
9. 尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。
10.测试要尽可能地小，执行速度快。
事实上，JUnit还可用于集成测试，但我并没涉及到，原因有两个：一是因为没有单元测试，集成测试无从谈起。我们接受测试地概念已经很不容易了，如果再引入集成测试就会更困难。二是我比较懒，希望将集成测试的任务交给测试人员去做。在JUnit的网站上有一些相关的文章，有空大家可以翻一翻。
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 了解不多，所以无法做出合适的建议。希望各位先知们能不吝赐教。
正是由于JUnit的开放性和简单易行，才会引出这篇介绍文章。但技术总在不断地更新，而且我对测试并没有非常深入的理解;我可以将一个复杂的概念简化成一句非常容易理解的话。但我的本意只是希望能降低开发人员步入测试领域的门槛，而不是要修改或重新定义一些概念。这一点是特别要强调的。最后，如果有些兄弟姐妹能给我指出一些注意事项或我对某些问题的理解有误，我会非常感激的。
文章来源于领测软件测试网 https://www.ltesting.net/
