开发单元测试脚手架 - 第一篇 - 需求分析
文档计划（暂定）
| 文档名称 | 计划完成时间 | 完成状态 |
| 第一篇 - 需求分析 | 2011-7-28 |  |
| 第二篇 - 插件扩展点 | 2011-7-30 | |
| 第三篇 - JDT的AST模型 | 2011-7-30 | |
| 第四篇 - JDT解析业务代码 | 2011-7-31 | |
| 第五篇 - JDT生成单元测试 |
2011-7-31 |
寄语
今天给其他同事做了单元测试脚手架的分享，但是效果感觉不佳，因为我只是懵懵懂懂做好了，而后模模糊糊地重构优化了，但是怎样把这些经验、技术很好的表达出来，我确实还非常欠缺想法和实战经验，所以开始编写这几篇连载，想设法清晰地表达我开发这个插件的过程中遇到的各种各样的问题、以及解决思路。
前言
Boss常说：工具能做的事情，不要让工程师来做，尽量交给工具。而工程师应该将他们的思维和智慧用于更具创造力的地方。
什么是单元测试脚手架
首先，介绍一下什么是单元测试脚手架，意思是：你拿到一段需要做单元测试的代码，扔给这个插件，它会根据代码的一些特点，帮忙生成一些有规律的代码骨架，而后骨架里要放些什么馅儿之类的，就由开发者自己编写了。
还是举个例子吧。
对了，本文假定你也经常用某些框架来编写单元测试代码，最好就是跟笔者一样用的是JTester框架，如果实在不是，只要用过JMockit或者类似的就成。
有这样一个业务类代码：
public class DemoService {
BizSerivce bizSvr;
DataService dtSvr;
......
public int doBiz() {
return dtSvr.update(bizSvr.findById(1L));
}
}
在单元测试的概念中，定义bizSvr, dtSvr这样的成员变量为外部依赖，我们并不关注它们的实现，所以我们在编写单元测试代码的时候，通常会把它们mock掉。
在JTester中，通常会这样写DemoService的单元测试：
public class DemoServiceTest extends JTester {
@SpringBeanByName
DemoService demoService;
@SpringBeanFor
@Mocked
BizSerivce bizSvr;
@SpringBeanFor
@Mocked
DataService dtSvr;
@Test
public void test_doBiz() {
new Expectations(){
{
bizSvr.findById(anyLong);
result = ......;
dtSvr.update();
result = 1;
}
};
want.number(demoService.doBiz()).isEqualTo(1);
}
}
脚手架可以做的事情
细心观察这段代码，不难发现，这个单元测试类DemoServiceTest中，成员变量的声明、测试方法test_doBiz的声明、测试方法内的Expectations的创建代码中的mock代码，都是有规律可循的。
脚手架不能做的事情
我们所无法帮助编码者判断的是，这些mock代码需要返回什么值，它的入参可能是什么值，最终want.number()断言里会期望怎样的返回值。
需求明确了
这样脚手架的需求便明确了——为一个业务方法生成单元测试类，它当中会包括被测业务类、外部依赖类的声明、单元测试方法的声明以及方法调用的mock信息。