本月的课题是在研发团队中推广Enterprise Java的单元测试，说是单元测试，其实很大程度上是单元测试和验收测试的一个综合产物。在2003年的大连，elian同学就高瞻远瞩的提出我们做的既不是白盒测试，也不是黑盒测试，而是灰盒测试。神人啊。在实践Fit，Selenium，dbunit以及很多xUnit扩展，各有优缺点。
看过若干本xUnit方面的书籍，也在项目中实践过，那时我还是个一门心思做研发的坏脾气小子，挺不配合测试人员的工作（但现在许多开发人员对测试人员的态度，我实在是不想提了，要是按照我当年的脾气，非重打100杀威棒并拖出去喂狗不可），后来我迷上了需求管理，再后来我发现真正的让需求不虚的研发方式是：测试驱动开发（Test Driven Development）。
有这种豁然开朗的心得，不是在C++的开发环境下，也不是“集尔意意（J2EE，某客户读音）”的开发团队中，而是在使用Rails时。Rails有千般好，我在这里不想细说。有一点是，当你用过了Ruby on Rails 后，你基本上不想再碰java的哪怕一行代码，特别是在用rails做完了单元测试和功能性测试之后。Rails对单元测试和功能性测试的支持，那叫一个绝啊。
可是大部分的开发人员不像我这样，可以轻松切换到J2EE之外的平台，所以还是要做JavaEE下的单元测试推广，如果谁想跟我说，用junit啊，我相信他基本上就没有真正的写单元测试。由于过渡的采用了若干的模式、分层。。。要在J2EE开发团队中推单元测试还真不是件易事，更不用说是在那些个“累死了都不应该可怜的”觉着“单元测试是测试人员应该做的事”的开发人员的团队中推广了。
其实路子是已经成熟了的，主要的问题是谁也不愿意费力，潜台词是：我宁愿重启若干次服务器来调试，我宁愿reopen若干次bug，也不愿意接触“新”玩意.这玩意新吗？这玩意真得浪费了你宝贵的时间吗？做程序员做到这个份上，真是悲哀。
其实也难怪，看一下一段java代码：
import java.util.List;
import java.util.ArrayList;
class Erase {
private List filterLongerThan(List strings, int length) {
List result = new ArrayList();
for (int i = 0; i < strings.size(); i++) {
String s = (String) strings.get(i);
if (s.length() <= length) {
result.add(s);
}
}
return result;
}
public static void main(String[] args) {
List names = new ArrayList();
names.add("Ted"); names.add("Fred");
names.add("Jed"); names.add("Ned");
System.out.println(names);
Erase e = new Erase();
List shortNames = e.filterLongerThan(names, 3);
System.out.println(shortNames.size());
for (int i = 0; i < shortNames.size(); i++) {
String s = (String) shortNames.get(i);
System.out.println(s);
}
}
}
要达到同样的效果，用同样运行在java 虚拟机中的groovy脚本再写：
names = ["Ted", "Fred", "Jed", "Ned"]
println names
shortNames = names.findAll{ it.size() <= 3 }
println shortNames.size()
shortNames.each{ println it }
别跟我提性能哈，就像当年我用c++写程序时，java开发人员跟我说的那样：现在内存这么便宜，多买点不就行了。
扯远了，J2EE下的单元测试，如果能够跟groovy结合着就好了。
发表于 @ 2008年04月01日 20:05:00|评论(loading...)|编辑