好象貌似有本书是用写一个JUnit作为例子来讲解TDD的。要说TDD绝对是个好东西,不过TDD本身并不能保证搞出好软件。这不,Junit就是个活生生的例子呀。
一直以来,我写Junit+Easymock测试都是这么来的:
[code]
public class SomeTest extends TestCase {
private final IMocksControl control = EasyMock.createStrictControl();
private final Connection connection = control.createMock(Connection.class);
@Override protected void tearDown() {
control.verify();
// other cleanups.
}
public void test1() {
expect(connection.createStatement()).andReturn(null);
...
control.replay();
...
}
}
[/code]
不要细抠具体的mock用法,我这都是临时编的。但是这个测试类有两个肥肠严重的问题。说起来我一直都是这么做的,真是愧对付给我工资的那些老板们啊!
第一个问题:
JUnit里面不应该用field initializer的——或者说,不能用构造函数来初始化test fixture的。当调用new TestSuite(SomeTest.class)的时候,JUnit系统会对每一个testSomething()函数调用一次构造函数,生成一个独立的test instance. 这样做,保证了每个测试的独立性,最大程度地避免了某个test case影响其它test case的出现。
不过,“等等”,你说。这不是正好就对了么?每个test case都会调用一遍这些field initializer,没有任何问题了呀?
是呀,所以我才这么多年一直理直气壮,厚颜无耻地用这个idiom呀,用这个idiom。直到最近,同事中的java专家告诉我,这是不安全地,不道德地,是低级趣味地!
因为JUnit在没有执行test case,只是构造test suite的时候,就调用了这些构造函数,这就造成了几个额外问题:
1。这造成TestSuite的创建不够安全,有可能出现异常——我们希望异常只出现在test case运行的时候。并且TestSuite的创建速度也有可能受到影响。
2。我们无法保证一个TestCase只被运行一次。比如说RepeatedTest就会多次运行一个TestCase。所以保证TestCase至少看上去是immutable的就比较重要了。
第二个问题:
不应该在tearDown()里面调用verify()。如果test case失败了,首先这个verify()就没有调用的必要了。不应该用tearDown()来强制调用它。其次,如果verify()也失败(相当有可能地),那么后一个exception会冲掉前面的那个(JUnit 4里面修好了这个bug),而前面那个exception才是你真正需要的呀。
而且,如果verify()失败了,那么后面的other cleanups也被跳过去了,而它们才是最最重要的呀。
你说可气不可气?我还以为JUnit这么简单的东西,肯定不会用错的呢。
但是,让我不许定义final field,让我把所有的初始化都放在setUp里面,让我在tearDown里面一个接一个地套try-finally,这,这不是代码难看的问题,这是太没人性了!
我想啊想,终于顿悟了。这不是人民内部矛盾,而是不可调和的阶级冲突啊。
JUnit不同于TestNG, 它极度强调测试的隔离性,为此不惜禁止我们在一个测试类中共享一些有用的信息(比如,一个parse好的xml数据之类),每个test method都将使用一个单独的instance。可是,如此代价换来的居然还是一个不干不嘎的局面:我们还是不能假设一个instance只被用一次。它肯定不会被两个不同的test method使用地,——但是它可以被一个test method重复使用啊。哈,哈,哈。没想到吧?
到了JUnit 4, tearDown的问题解决了。我可以在每个@After函数中释放各自的资源,框架会保证它们都被执行。不过,我们还是不能在@After的函数中调用verify(), 还是因为对于verify()我们并不希望在测试本身失败的时候还调用它。
至于构造函数问题,没有任何改善,没有。同样,JUnit 4也没有正视广大人民群众对共享数据的呼声。不管TestSetup还是@BeforeClass都是要求你用evil static field。
忍无可忍之下,我又怒了。于是自己写了一个AjooTestSuite,偷偷从TestNG搞来了几个我一直非常眼馋的annotation: @BeforeTest, @AfterTest, @BeforeSuite, @AfterSuite, @ExceptionExpected。又自己填了两个@Verify和@Shared。前者用来在测试没出问题的情况下做一个公用的verify,比如verify mock object;后者用来在test case之间共享数据。一个使用AjooTestSuite的测试类可以这么写:
[code]
public class SomeTest extends TestCase {
public static Test suite() {
return new AjooTestSuite(SomeTest.class);
}
// 哈哈。终于可以用final和initializer了!
private final IMocksControl control = EasyMock.createStrictControl();
private final Connection conn = control.createMock(Connection.class);
@Verify
public void verifyMocks() {
control.verify();
}
@Shared
public static XmlObject provideXml() {
// ... read xml file and parse.
return xmlObj;
}
private final XmlObj;
// the shared xmlObj will be injected for each test case.
public SomeTest(String name, XmlObject obj) {
super(name);
this.xmlOj = obj;
}
@BeforeSuite
public static void initialize() {
// some suite level initialization. No more TestSetup!
}
@AfterSuite
public static void deinitialize() {
// suite level deinitialization.
}
@BeforeTest
public void setupMocks() {
expect(conn.createStatement()).andReturn(null);
}
@ExceptionExpected(NullPointerException.class)
public void test1() {
throw new NullPointerException();
}
}
[/code]
写完之后,我这个得意呀。终于不用忍受JUnit屎一样的限制了。构造函数只有在测试运行的时候才调用,换句话说,这回test case是绝对immutable的了,绝对线程安全。耶!
除此之外,还加上了一些流行的annotation。@BeforeTest, @AfterTest, @BeforeSuite, @AfterSuite,@ExceptionExpected不用说,都跟TestNG一样的语义。@Verify用来搞类似verify mock之类的事情;@Shared标注的静态函数在每次test suite执行的时候会被调用一次,返回的数据会被保存并被注射给每一个test case instance。
完美呀,完美。这样一来,也不用转移到TestNG了,也不用忍受一些工具集成的问题升级到JUnit4了。就是一个新的TestSuite而已,100%向后兼容。
可是,事实证明,我说的太早了。我的java专家同事又给我泼了一瓢凉水:
现在,你在Eclipse/Intellij里面点运行,没问题,它会知道去寻找suite()函数,然后用你的自定义test suite。可是,如果你然后点某一个单独的test case, 比如test1, 然后说"run"。会发生什么哩?嘿嘿,它不再去找你的suite()函数啦,啦,啦,啦,啦(回声逐渐消失)。它直接跑到你的类里面去找这个函数来调用了。Surprise!
天啊。该死的Eclipse, 它难道不会调用suite(), 然后在suite()里面找么?
可仔细想想,又不是IDE的错。即使它调用suite()又如何?没有一个TestSuite.getTest(String name)的API供它调用啊。实际上,JUnit的TestCase也并不强制保证每个Test都有一个id的。
于是,我三天的工作白费了。呜呜呜!
总而言之,言而总之,千言万语,咬牙切齿汇成一句话:JUnit Sucks!
一直以来,我写Junit+Easymock测试都是这么来的:
[code]
public class SomeTest extends TestCase {
private final IMocksControl control = EasyMock.createStrictControl();
private final Connection connection = control.createMock(Connection.class);
@Override protected void tearDown() {
control.verify();
// other cleanups.
}
public void test1() {
expect(connection.createStatement()).andReturn(null);
...
control.replay();
...
}
}
[/code]
不要细抠具体的mock用法,我这都是临时编的。但是这个测试类有两个肥肠严重的问题。说起来我一直都是这么做的,真是愧对付给我工资的那些老板们啊!
第一个问题:
JUnit里面不应该用field initializer的——或者说,不能用构造函数来初始化test fixture的。当调用new TestSuite(SomeTest.class)的时候,JUnit系统会对每一个testSomething()函数调用一次构造函数,生成一个独立的test instance. 这样做,保证了每个测试的独立性,最大程度地避免了某个test case影响其它test case的出现。
不过,“等等”,你说。这不是正好就对了么?每个test case都会调用一遍这些field initializer,没有任何问题了呀?
是呀,所以我才这么多年一直理直气壮,厚颜无耻地用这个idiom呀,用这个idiom。直到最近,同事中的java专家告诉我,这是不安全地,不道德地,是低级趣味地!
因为JUnit在没有执行test case,只是构造test suite的时候,就调用了这些构造函数,这就造成了几个额外问题:
1。这造成TestSuite的创建不够安全,有可能出现异常——我们希望异常只出现在test case运行的时候。并且TestSuite的创建速度也有可能受到影响。
2。我们无法保证一个TestCase只被运行一次。比如说RepeatedTest就会多次运行一个TestCase。所以保证TestCase至少看上去是immutable的就比较重要了。
第二个问题:
不应该在tearDown()里面调用verify()。如果test case失败了,首先这个verify()就没有调用的必要了。不应该用tearDown()来强制调用它。其次,如果verify()也失败(相当有可能地),那么后一个exception会冲掉前面的那个(JUnit 4里面修好了这个bug),而前面那个exception才是你真正需要的呀。
而且,如果verify()失败了,那么后面的other cleanups也被跳过去了,而它们才是最最重要的呀。
你说可气不可气?我还以为JUnit这么简单的东西,肯定不会用错的呢。
但是,让我不许定义final field,让我把所有的初始化都放在setUp里面,让我在tearDown里面一个接一个地套try-finally,这,这不是代码难看的问题,这是太没人性了!
我想啊想,终于顿悟了。这不是人民内部矛盾,而是不可调和的阶级冲突啊。
JUnit不同于TestNG, 它极度强调测试的隔离性,为此不惜禁止我们在一个测试类中共享一些有用的信息(比如,一个parse好的xml数据之类),每个test method都将使用一个单独的instance。可是,如此代价换来的居然还是一个不干不嘎的局面:我们还是不能假设一个instance只被用一次。它肯定不会被两个不同的test method使用地,——但是它可以被一个test method重复使用啊。哈,哈,哈。没想到吧?
到了JUnit 4, tearDown的问题解决了。我可以在每个@After函数中释放各自的资源,框架会保证它们都被执行。不过,我们还是不能在@After的函数中调用verify(), 还是因为对于verify()我们并不希望在测试本身失败的时候还调用它。
至于构造函数问题,没有任何改善,没有。同样,JUnit 4也没有正视广大人民群众对共享数据的呼声。不管TestSetup还是@BeforeClass都是要求你用evil static field。
忍无可忍之下,我又怒了。于是自己写了一个AjooTestSuite,偷偷从TestNG搞来了几个我一直非常眼馋的annotation: @BeforeTest, @AfterTest, @BeforeSuite, @AfterSuite, @ExceptionExpected。又自己填了两个@Verify和@Shared。前者用来在测试没出问题的情况下做一个公用的verify,比如verify mock object;后者用来在test case之间共享数据。一个使用AjooTestSuite的测试类可以这么写:
[code]
public class SomeTest extends TestCase {
public static Test suite() {
return new AjooTestSuite(SomeTest.class);
}
// 哈哈。终于可以用final和initializer了!
private final IMocksControl control = EasyMock.createStrictControl();
private final Connection conn = control.createMock(Connection.class);
@Verify
public void verifyMocks() {
control.verify();
}
@Shared
public static XmlObject provideXml() {
// ... read xml file and parse.
return xmlObj;
}
private final XmlObj;
// the shared xmlObj will be injected for each test case.
public SomeTest(String name, XmlObject obj) {
super(name);
this.xmlOj = obj;
}
@BeforeSuite
public static void initialize() {
// some suite level initialization. No more TestSetup!
}
@AfterSuite
public static void deinitialize() {
// suite level deinitialization.
}
@BeforeTest
public void setupMocks() {
expect(conn.createStatement()).andReturn(null);
}
@ExceptionExpected(NullPointerException.class)
public void test1() {
throw new NullPointerException();
}
}
[/code]
写完之后,我这个得意呀。终于不用忍受JUnit屎一样的限制了。构造函数只有在测试运行的时候才调用,换句话说,这回test case是绝对immutable的了,绝对线程安全。耶!
除此之外,还加上了一些流行的annotation。@BeforeTest, @AfterTest, @BeforeSuite, @AfterSuite,@ExceptionExpected不用说,都跟TestNG一样的语义。@Verify用来搞类似verify mock之类的事情;@Shared标注的静态函数在每次test suite执行的时候会被调用一次,返回的数据会被保存并被注射给每一个test case instance。
完美呀,完美。这样一来,也不用转移到TestNG了,也不用忍受一些工具集成的问题升级到JUnit4了。就是一个新的TestSuite而已,100%向后兼容。
可是,事实证明,我说的太早了。我的java专家同事又给我泼了一瓢凉水:
现在,你在Eclipse/Intellij里面点运行,没问题,它会知道去寻找suite()函数,然后用你的自定义test suite。可是,如果你然后点某一个单独的test case, 比如test1, 然后说"run"。会发生什么哩?嘿嘿,它不再去找你的suite()函数啦,啦,啦,啦,啦(回声逐渐消失)。它直接跑到你的类里面去找这个函数来调用了。Surprise!
天啊。该死的Eclipse, 它难道不会调用suite(), 然后在suite()里面找么?
可仔细想想,又不是IDE的错。即使它调用suite()又如何?没有一个TestSuite.getTest(String name)的API供它调用啊。实际上,JUnit的TestCase也并不强制保证每个Test都有一个id的。
于是,我三天的工作白费了。呜呜呜!
总而言之,言而总之,千言万语,咬牙切齿汇成一句话:JUnit Sucks!