ajoo

记得以前曾经和一个tw出来的老兄一起共事过一小段时间。当时问他们组的测试情况，据说都是100%的覆盖率。说实话，心里挺惊讶的。

我不是一个懒于写测试的人。实际上，通过是否便于测试来判断一段代码的设计优劣已经几乎是本能了。可是，我发现连九成的覆盖率对我来说都是几乎难以企及的目标。

你的代码不管怎么重构，总有那么一些角落要连数据库，写文件，从信用卡里面划钱这些恶心吧唧的东西吧？这些应该都可以集成测试，但是单元测试我基本上就是绕过了。

这也罢了。那些java bean的getter/setter你难道也要测？一行的throw new UnsupportedOperationException()难道也要测？

最近和同事有一个有趣的讨论。原因是这么一个简单的函数：

void copy(Source source, Dest dest) {
  dest.setFoo(source.foo());
  dest.setBar(source.baz());
  // 不拷贝baz，baz的处理在别的地方做。
  // 还有其他的乱七八糟的拷贝
}

我以为这么一个简单地几乎代码本身就相当于需求描述的东西没必要费劲写单元测试了。但是发现很多同事不是这么看，不管从tdd的角度还是纯朴地希望测试所有能测的东西的愿望都促使大家异口同声地说：测！

那么，怎么测呢？这里面除了要测试foo和bar拷贝了，还要测试baz没有拷贝。大概是这么写吧：

Source source = new Source();
source.setFoo("foo");
source.setBar("bar");
source.setBaz("baz");
Dest dest = new Dest();
copy(source, dest);
assertEquals("foo", dest.getFoo());
assertEquals("bar", dest.bar());
assertNull(dest.baz());

可是那么简单的原始代码就要用这么一堆杂乱的测试么？怎么想怎么不值啊。


我自己有这么一个小理论：


我这个小理论的前提是，T比P简单。所以对getter/setter这种，因为我无法写出比生产代码更简单地测试代码了，所以测试的有效范围到此结束；而对一些仍然比较复杂的测试代码，这个迭代会继续下去，写额外的测试代码来测试这个测试代码，直到我可以把P递减到T1, T2, ..., Tn，最后无法写出一个更简单的T来测试Tn，循环结束。

用这个理论来衡量，上面的那个测试代码明显比生产代码复杂，可读性也差。所以在我看来属于不经济的。

当然，测试什么“没有作”目前最好的方式其实不是这种state-based testing，而是interaction-based，比如用EasyMock。当然，EasyMock的expectation语法写出来会是象咳嗽一样地：

expect(source.getFoo()).andReturn("foo");
dest.setFoo("foo");
expect(source.getBar()).andReturn("bar");
dest.setBar("bar");
// 不用管baz了，所有我们没说的一概不允许发生！

还是不如生产代码看着舒服，其复杂度大致是原来的两倍上下。

好吧，这只是EasyMock个人的问题。让我们来乐观一下，假设EasyMock可以被改进，支持直接用

dest.setFoo(source.getFoo());

这种更直观的方式来写expectation，那么上面的测试代码就可以简化许多了，理想情况下，我们就可以把它写成：

dest.setFoo(source.getFoo());
dest.setBar(source.getBar());
// do not copy baz as it is taken care of separately
// other set(get())

嗯。漂亮许多。不再那么唧唧歪歪了。可是，你发现了什么没有？这个测试代码可以直接从生产代码拷贝过来！

也就是说，最最好的情况下，我们不过是在重复小时候淘气被老师惩罚的惨无人道的抄课文！

记得我是一个老实孩子，作弊都不会，老师让抄五遍的，我偷了妈妈的复写纸还是老老实实地写了三遍

不过现在不同了，我们都是聪明的程序员，既然可以直接copy-paste的，那也就没什么麻烦的了。不管多少字，都是两下按键潇洒搞定。可是，这样一来，测试就没有意义了呀，搞什么搞嘛。

你也许会说：你用复写纸当然起不到作用了，老师是让你用人肉来写的，这样才能锻炼书法，记忆力，毅力，恒心，专心，责任心，爱心等等的嘛。

或者比如说你登录一个帐号，要输入密码的时候，不是要同样的密码用人肉敲两遍，而不是拷贝的么？

是哈，看来EasyMock不做得象复写纸那么方便还是有道理的，头悬梁椎刺骨，吃得苦中苦，方为人上人，设计的真是人性化啊。

不过，我还是总觉得有那么一点别扭。能（假设能）拷贝的非要装作不能，拿手去重新写一遍总是觉得有点象苏哥，一边说自己是救世主，一边人家随便一弄就搞死了那么的不通。要说多写一边能帮助避免错误，那为啥不写5遍？（恩，也许NASA这种关键部门的关键程序就是让程序员默写50遍的──这些程序员肯定是小学留级10年以上的问题学生来的）

今天，又遇到一个问题，想了想，觉得我要是提出来，肯定还是要被大家批判得体无完肤的。生产代码里面需要调用某个Service，需要传递一个固定的map进去：

Map<String, String> params(int id) {
  return ImmutableMap.of(
    "m", "Get",
    "id", id
  );
}

void doFoo(int id) {
  service.call(params(id));
}

然后在mock测试doFoo的时候，我就想，我是这样呢？

service.call(ImmutableMap.of(
    "m", "Get",
    "id", id
  ));

replay();

doFoo(id);

还是这样呢？

service.call(Foo.params(id));

replay();

doFoo(id);

后者如果Foo.params()写错了，测试也就错了。

又或者，我应该写一个Foo.params()的测试？这样？

assertEquals(ImmutableMap.of(
    "m", "Get",
    "id", id
  ), Foo.params(id));

也许，通过抄课文，重复输入密码这些高科技手段，我的程序质量会不知不觉地提高？或者至少下次别人维护我的程序的时候，不小心改错一个地方，测试会报错。而且，当他看到我的测试代码和生产代码长得一模一样，就会发出会心的微笑：根据ajoo的人格，他肯定不是用复写纸作弊地。看来他的目的确实是这个了，写了两遍都是一模一样的。闹得闹得。