51Testing软件测试论坛

标题: JUnit最佳实践<转载> [打印本页]

作者: bhb 时间: 2004-9-15 15:02
标题: JUnit最佳实践<转载>
JUnit最佳实践
JUnit是什么？
cherami
JUnit是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。它包括以下特性：
1、用于测试期望结果的断言（Assertion）
2、用于共享共同测试数据的测试工具
3、用于方便的组织和运行测试的测试套件
4、图形和文本的测试运行器
JUnit最初是由Erich Gamma（GoF之一）和Kent Beck（xp和refactor的先驱之一）编写的.
需要说明的是junit一般是用来进行单元测试的，因此需要了解被测试代码的内部结构（即所谓的白盒测试），另外junit是在xp编程和重构（refactor）中被极力推荐使用的工具，因为在实现自动单元测试的情况下可以大大的提高开发的效率，但是实际上编写测试代码也是需要耗费很多的时间和精力的，那么使用这个东东好处到底在哪里呢？笔者认为是这样的：
1、对于xp编程而言，要求在编写代码之前先写测试，这样可以强制你在写代码之前好好的思考代码（方法）的功能和逻辑，否则编写的代码很不稳定，那么你需要同时维护测试代码和实际代码，这个工作量就会大大增加。因此在xp编程中，基本过程是这样的：构思－》编写测试代码－》编写代码－》测试，而且编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较块的追踪到问题的原因，减小回归错误的纠错难度
2、对于重构而言，其好处和xp编程中是类似的，因为重构也是要求改一点测一点，减少回归错误造成的时间消耗。
3、对于非以上两种情况，我们在开发的时候使用junit写一些适当的测试也是有必要的，因为一般我们也是需要编写测试的代码的，可能原来不是使用的junit，如果使用junit，而且针对接口（方法）编写测试代码会减少以后的维护工作，例如以后对方法内部的修改（这个就是相当于重构的工作了）。另外就是因为junit有断言功能，如果测试结果不通过会告诉我们那个测试不通过，为什么，而如果是想以前的一般做法是写一些测试代码看其输出结果，然后再由自己来判断结果使用正确，使用junit的好处就是这个结果是否正确的判断是它来完成的，我们只需要看看它告诉我们结果是否正确就可以了，在一般情况下会大大提高效率。
JUnit入门
cherami 整理
安装JUnit
安装很简单，先到以下地址下载一个最新的zip包：
http://download.sourceforge.net/junit/
下载完以后解压缩到你喜欢的目录下，假设是JUNIT_HOME，然后将JUNIT_HOME下的junit.jar包加到你的系统的CLASSPATH环境变量中，对于IDE环境，对于需要用到的junit的项目增加到lib中，其设置不同的IDE有不同的设置，这里不多讲。
如何使用JUnit写测试？
最简单的范例如下：
1、创建一个TestCase的子类:
package junitfaq;
import java.util.*;
import junit.framework.*;
public class SimpleTest extends TestCase {
public SimpleTest(String name) {
super(name);
}
2、写一个测试方法断言期望的结果：
public void testEmptyCollection() {
Collection collection = new ArrayList();
assertTrue(collection.isEmpty());
}
注意：JUnit推荐的做法是以test作为待测试的方法的开头，这样这些方法可以被自动找到并被测试。
3、写一个suite()方法，它会使用反射动态的创建一个包含所有的testXxxx方法的测试套件：
public static Test suite() {
return new TestSuite(SimpleTest.class);
}
4、写一个main()方法以文本运行器的方式方便的运行测试：
public static void main(String args[]) {
junit.textui.TestRunner.run(suite());
}
}
5、运行测试：
以文本方式运行：
java junitfaq.SimpleTest
通过的测试结果是：
.
Time: 0
OK (1 tests)
Time上的小点表示测试个数，如果测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。
每次的测试结果都应该是OK的，这样才能说明测试是成功的，如果不成功就要马上根据提示信息进行修正了。
如果JUnit报告了测试没有成功，它会区分失败（failures）和错误（errors）。失败是你的代码中的assert方法失败引起的；而错误则是代码异常引起的，例如ArrayIndexOutOfBoundsException。
以图形方式运行：
java junit.swingui.TestRunner junitfaq.SimpleTest
通过的测试结果在图形界面的绿色条部分。
以上是最简单的测试样例，在实际的测试中我们测试某个类的功能是常常需要执行一些共同的操作，完成以后需要销毁所占用的资源（例如网络连接、数据库连接，关闭打开的文件等），TestCase类给我们提供了setUp方法和tearDown方法，setUp方法的内容在测试你编写的TestCase子类的每个testXxxx方法之前都会运行，而tearDown方法的内容在每个testXxxx方法结束以后都会执行。这个既共享了初始化代码，又消除了各个测试代码之间可能产生的相互影响。
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和ant结合
cherami 转贴
ant 提供了两个 target ： junit 和 junitreport
运行所有测试用例，并生成 html 格式的报表
具体操作如下：
1.将 junit.jar 放在 ANT_HOME\lib 目录下
2.修改 build.xml ，加入如下内容：
<property name="report" value="report" /> <target name="junitreport" depends="clean, compile"> <junit printsummary="on" fork="true" haltonfailure="false" failureproperty="tests.failed" showoutput="true"> <classpath refid="myclasspath"/> <formatter type="xml"/> <batchtest todir="${report}"> <fileset dir="${build}"> <include name="**/*Test.*"/> </fileset> </batchtest> </junit> <junitreport todir="${report}"> <fileset dir="${report}"> <include name="TEST-*.xml"/> </fileset> <report format="frames" todir="${report}"/> </junitreport> <fail if="tests.failed"> --------------------------------------------------------- One or more tests failed, check the report for detail... --------------------------------------------------------- </fail> </target>
运行这个 target ，ant 会运行每个 TestCase
在 report 目录下就有了很多 TEST*.xml 和一些网页
打开 report 目录下的 index.html 就可以看到很直观的测试运行报告，一目了然

作者: mojinde 时间: 2005-2-25 17:03
看这些有关JUNIT的资料，给我的感觉就是，用它来作单元测试，都是开发人员来做的，所以我想，做为我们测试人员，不编写源码，那怎样用JUNIT来做测试呢？

作者: someone5 时间: 2005-4-6 12:16
测试人员如果要作组件测试的话,也是要编写代码的啊.我们目前就是在用Nunit做测试,不过还在研究阶段,用得还不是很好,呵呵

作者: weisai 时间: 2005-9-5 17:05
to mojinde:
單元測試是保證每一塊塼，每一根鋼筋都是合格的
而測試人員是為了保證每一個房間都讓人住的舒服

作者: niuniu_8000 时间: 2006-3-1 12:10
根据楼上所说，是不是单元测试需要将逻辑层的每个函数调用都要测试一下，还是选择性的测试，如果是选择性的测试应该如果做出选择？
本人是刚开始做白盒，感觉无从下手，请高手指点迷津！！！

作者: 梦水恒欣 时间: 2006-3-27 11:56
我怎么无法下载呀？

作者: ljdlx 时间: 2006-8-8 14:15
选择性测试应该是针对于代码的长度,复杂度,重要性来确定是否做白盒测试吧,比如说小于30行的代码,可以进行走读测试,没必要做白盒测试,对于重要的代码需要分析其分支、路径，条件，根据不同的情况来做一个测试用例吧，我是这么理解的，不知道对不对！

作者: wanghong 时间: 2006-8-17 17:39
标题: 各位兄弟要与时代同步呀
难到大家写JUnit的测脚本还没有写累吗，单元测试不是这样做的，需要自动化，现在国外全是自动化的单元测试了，JUnit的创始人kentBeck又推出了新的JAVA单元测试工具——Agitar，详情：www.madetek.com

作者: carol_0921 时间: 2007-12-4 22:14
刚被借调到一个部门，以为可以有机会接触一下junit，结果，人家直接来一句，做功能测试。这个都是开发人员在做。。又无望了。

作者: cangmang 时间: 2008-2-18 15:33

原帖由 weisai 于 2005-9-5 17:05 发表
to mojinde:
單元測試是保證每一塊塼，每一根鋼筋都是合格的
而測試人員是為了保證每一個房間都讓人住的舒服

4楼的同学理解的太片面了吧.....易用性只不过是测试人员的任务之一而已...

作者: huiguiziran111 时间: 2009-5-21 11:39
我不愿意做单元测试的

作者: haibinpark 时间: 2012-2-24 14:30
谢谢分享。

作者: 天地灭 时间: 2012-8-3 14:19

作者: Miss_love 时间: 2014-6-26 18:03
ganx感谢分享

作者: fhhh_eyou 时间: 2016-3-12 12:11
学习，谢谢！感谢分享。

作者: 51testing.jing 时间: 2017-1-4 15:35
我想说有没有测试程序的结果截图

作者: kz东方 时间: 2018-1-30 15:29
单元测试的用例应该是测试人员来写的，具体代码实现由开发人员写，开发人员写完，测试人员检查覆盖率与业务场景是否全面

作者: kz东方 时间: 2018-1-30 15:31
对于一个可以做白盒测试人员来说，适当编写单元测试也没什么问题（不影响自己工作，毕竟测试不是一直有活干）

作者: kz东方 时间: 2018-2-6 14:27

mojinde 发表于 2005-2-25 17:03
看这些有关JUNIT的资料，给我的感觉就是，用它来作单元测试，都是开发人员来做的，所以我想，做为我们测试 ...

为什么测试人员不能写单元测试呢，我觉得能力到了，测试写没问题啊

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)