如何使用junit3进行程序测试

步骤一：构建环境

1

首先新建一个java project.，名字叫做junit3。在拘泥t中再构建一个source folder。目的是形成良好的变成风格。将源码放在src中将测试代码发在另一个source folder（名字叫做test）中。

形成的目录结构如图。

2

在src中和test中起相同名字的packet，这样编译后的class就在同一个目录下，不需要导入包即可。我的packet名字叫做（com.edu）

形成的目录结构如图所示。

3

构建完成包结构后，我们还需要导入junit3包。右击junit3，选择build path——add library——junit——junit3——finish.

形成的目录结构如图。

END

步骤二：使用Assert(单个测试)

1

首先在src的com.edu下面编写一个简单的被测试的程序。名字叫做AddMethod.代码如下。

2

对被测试程序进行测试。在test的com.edu下编写一个AddMethodTest类，继承TestCase。然后倒入junit.framework.TestCase包，快捷键（Ctrl+shift+o）,此时项目的结构如图。

3

此时我们就可以开始编写测试代码了。注意测试代码的方法一定要是public且void的。名字也要起得有符合规范，要么是testmethod要么是methodtest,推荐第一种。

4

由于测试的时候需要一些初始化工作，所以junit也提供了一些初始化的方法（setUp）,还有结束的处理（tearDown），我们运行一下程序就可以知道setUp和tearDown的作用了。

5

运行程序，右击AddMethodTest——run as——junit Test。

6

这个是简答的测试，没有什么实际意义。只是实现了他的过程。下面我们就完善testadd方法。测试通过后，进度条会是绿色的，没有通过的是红色的。因此，keep the bar green .

7

单个测试已经完成，另外assert有很多重载的方法，大家要自己看，还有Assert.fail（）方法。这个自己看。

END

步骤三：自动化测试（批量测试）

这个就是单个测试的升级版了，以阿奇那只能一个一个测试，现在我们可以一次把所有的classTest都执行了。为了演示自动化测试，我们需要多个测试类。我下卖弄再编写一个测试类。

然后编写自动化测试套件。在test中建一个TestAll代码和结构如下。

结果如下，可以看到两个类都测试了。注意punlic static Test suite()这句话一点都不能改。TestSuite实例可以进行套件测试。

还可以定义一个方法的执行重复次数，实例如下。

END

注意事项

注意在使用重复RepeatedTest测试的时候要重写测试方法的名字方法，只需要public 类名（String name）{super(name)；}即可

这个问题出现在这种情况，你的每个testCase都需要使用某一种初始化比较耗时的对象（资源），举例如数据库连接、Spring Context。我们遇到的问题是Selenium测试中开启和关闭浏览器，如果一个test启动关闭（我们的程序还需要登录和注销），这样测试的时间会 拖的很长，给持续集成带来了困难。

所以，我们需要在每组不会冲突的test中间共享一个浏览器窗口，这样也就需要一个全局的setUp和 tearDown。问题是JUnit 3.8.1里面的setUp和tearDown是在每个test之前和之后运行的，如果在里面初始化和关闭浏览器就会造成上面所说的问题。要解决它，就产 生了如下3种思路：

1、升级，使用JUnit4

JUnit4从TestNG里面吸取了两个注释：@BeforeClass和 @AfterClass

用它们注释过的方法就会只初始化一次，完全符合我们的需求。

public class SeleniumTestCase extends SeleneseTestCase4 {

protected static final Log log = LogFactory.getLog(SeleniumTestCase.class)

protected static Selenium selenium = null

@BeforeClass

public static void startSelenium() throws Exception {

log.debug("Starting Selenium")

selenium = SeleniumSession.getCurrentSession().getSelenium()

}

@AfterClass

public static void stopSelenium() throws Exception {

log.debug("Stoping Selenium")

selenium.stop()

}

}

这个里面的selenium = SeleniumSession.getCurrentSession().getSelenium()其实是个singleton，第一次open new，后来就直接返回selenium的instance（具体参考其它文章）。

这样做非常舒服，因为完全不是Trick，而是新的 feature，用起来踏实。这样，这个类的所有@Test就会公用一个selenium打开的浏览器了。

那么缺点是什么呢？缺点是放到CI环境 的时候如果使用我们习惯的Ant写执行脚本的话必须将Ant升级到1.7Beta3，因为Ant 1.6.5的Junit task不支持JUnit4……当然升级并不会带来代码的变化，但是问题在于Ant 1.7还是Beta，而且JUnit4需要JDK5的Annotation，你的PM估计要撇嘴了

2、JVM级别钩子法

因为JVM支持关闭时执行制定代码的钩子，而static代码会在类初始化时执行， 再加上Ant调用的是类似命令行的java命令，实际上每一个测试运行在一个完整的JVM启动关闭周期里面，所以也就产生了这种解决方案。

这个方 案来自taowen同学的两则Selenium经验。

代码我恢复了一下，大概是这样：

public abstract class SomeTestCase extends TestCase {

static {

// perform the "global" set up logic

//这里的代码会在类初始化时执行，所以相当于BeforeClass

log.debug("Starting Selenium")

selenium = SeleniumSession.getCurrentSession().getSelenium()

// and now register the shutdown hook for tear down logic

//将一个匿名方法写到这里，就相当于AfterClass

//给当前的进程注册一个清理线程，当进程退出的时候，会执行线程中的代 码。

Runtime.getRuntime().addShutdownHook(

new Thread(){

public void run() {

log.debug("Stoping Selenium")

selenium.stop()

}

}

)

}

}

这 个方法挺酷的，我认为完全可以被称作“奇技淫巧”。缺点就是，有点不好看。

3、还有别的方法，这个来自Selenium网站，似乎是不错 的中庸方案。

import junit.framework.*

import junit.extensions.TestSetup

public class AllTestsOneTimeSetup {

public static Test suite() {

TestSuite suite = new TestSuite()

suite.addTest(SomeTest.suite())

suite.addTest(AnotherTest.suite())

TestSetup wrapper = new TestSetup(suite) {

protected void setUp() {

oneTimeSetUp()

}

protected void tearDown() {

oneTimeTearDown()

}

}

return wrapper

}

public static void oneTimeSetUp() {

// one-time initialization code

}

public static void oneTimeTearDown() {

// one-time cleanup code

}

}

单元测试

如果你听说过“测试驱动开发”（TDD：Test-Driven Development），单元测试就不陌生。

单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。

比如对函数abs()，我们可以编写出以下几个测试用例：

输入正数，比如1、1.2、0.99，期待返回值与输入相同；

输入负数，比如-1、-1.2、-0.99，期待返回值与输入相反；

输入0，期待返回0；

输入非数值类型，比如None、[]、{}，期待抛出TypeError。

把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。

如果单元测试通过，说明我们测试的这个函数能够正常工作。如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。

单元测试通过后有什么意义呢？如果我们对abs()函数代码做了修改，只需要再跑一遍单元测试，如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的修改与原有行为不一致，要么修改代码，要么修改测试。

这种以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。

我们来编写一个Dict类，这个类的行为和dict一致，但是可以通过属性来访问，用起来就像下面这样：

>>>d = Dict(a=1, b=2)

>>>d['a']

1

>>>d.a

1

mydict.py代码如下：

class Dict(dict):

   def __init__(self, **kw):

       super(Dict, self).__init__(**kw)

   def __getattr__(self, key):

       try:

           return self[key]

       except KeyError:

           raise AttributeError(r"'Dict' object has no attribute '%s'" % key)

   def __setattr__(self, key, value):

       self[key] = value

为了编写单元测试，我们需要引入Python自带的unittest模块，编写mydict_test.py如下：

import unittest

from mydict import Dict

class TestDict(unittest.TestCase):

   def test_init(self):

       d = Dict(a=1, b='test')

       self.assertEquals(d.a, 1)

       self.assertEquals(d.b, 'test')

       self.assertTrue(isinstance(d, dict))

   def test_key(self):

       d = Dict()

       d['key'] = 'value'

       self.assertEquals(d.key, 'value')

   def test_attr(self):

       d = Dict()

       d.key = 'value'

       self.assertTrue('key' in d)

       self.assertEquals(d['key'], 'value')

   def test_keyerror(self):

       d = Dict()

       with self.assertRaises(KeyError):

           value = d['empty']

   def test_attrerror(self):

       d = Dict()

       with self.assertRaises(AttributeError):

           value = d.empty

编写单元测试时，我们需要编写一个测试类，从unittest.TestCase继承。

以test开头的方法就是测试方法，不以test开头的方法不被认为是测试方法，测试的时候不会被执行。

对每一类测试都需要编写一个test_xxx()方法。由于unittest.TestCase提供了很多内置的条件判断，我们只需要调用这些方法就可以断言输出是否是我们所期望的。最常用的断言就是assertEquals()：

self.assertEquals(abs(-1), 1) # 断言函数返回的结果与1相等

另一种重要的断言就是期待抛出指定类型的Error，比如通过d['empty']访问不存在的key时，断言会抛出KeyError：

with self.assertRaises(KeyError):

   value = d['empty']

而通过d.empty访问不存在的key时，我们期待抛出AttributeError：

with self.assertRaises(AttributeError):

   value = d.empty

运行单元测试

一旦编写好单元测试，我们就可以运行单元测试。最简单的运行方式是在mydict_test.py的最后加上两行代码：

if __name__ == '__main__':

   unittest.main()

这样就可以把mydict_test.py当做正常的python脚本运行：

$ python mydict_test.py

另一种更常见的方法是在命令行通过参数-m unittest直接运行单元测试：

$ python -m unittest mydict_test

.....

----------------------------------------------------------------------

Ran 5 tests in 0.000s

OK

这是推荐的做法，因为这样可以一次批量运行很多单元测试，并且，有很多工具可以自动来运行这些单元测试。

setUp与tearDown

可以在单元测试中编写两个特殊的setUp()和tearDown()方法。这两个方法会分别在每调用一个测试方法的前后分别被执行。

setUp()和tearDown()方法有什么用呢？设想你的测试需要启动一个数据库，这时，就可以在setUp()方法中连接数据库，在tearDown()方法中关闭数据库，这样，不必在每个测试方法中重复相同的代码：

class TestDict(unittest.TestCase):

   def setUp(self):

       print 'setUp...'

   def tearDown(self):

       print 'tearDown...'

可以再次运行测试看看每个测试方法调用前后是否会打印出setUp...和tearDown...。

小结

单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。

单元测试的测试用例要覆盖常用的输入组合、边界条件和异常。

单元测试代码要非常简单，如果测试代码太复杂，那么测试代码本身就可能有bug。

单元测试通过了并不意味着程序就没有bug了，但是不通过程序肯定有bug。

---