意外收获,关于mock和stub。

记录一些自己的想法,边写边想吧。

这是之前写的一篇东西:[url="http://yuan.iteye.com/admin/blogs/452228"]从AWDWR中的depot思考软件设计[/url]
也许表达得不是很清楚……但我自己确确实实能感觉到自顶向下逐步细化需求的开发方式是很有好处的。

后来回头搜索以前JavaEye上TDD相关的讨论,主要是关于mock的,找到这篇文章:[url='http://www.iteye.com/topic/21630"]讨论《不要把Mock当作你的设计利器》[/url],以及这篇文章的主角:[url="http://news.csdn.net/n/20060726/93003.html"]不要把Mock当作你的设计利器[/url],感觉完全颠覆了我之前对mock的认识。好像大家都在说:只有对UI、第3方接口、I/O对象等这些创建的成本很高的对象有进行mock的必要。而我的认识一直是:当你正在测试的对象要调用另一个对象的时候,就要对另一个对象进行mock,从而隔离另一个对象具体的实现对当前对象的影响,这样使开发人员可以一次只关注一件事,完成一件事之后再去做另一件事。

想到这里,问题又来了:为什么不对String进行mock?String也是“其它对象”啊,难道只是因为它是已经实现了的类?这会脑子里有点乱……[url="http://mock1234.iteye.com]mock1234[/url]说“凡是考虑测试驱动必从突出集成测试这个概念入手”……Sun实现了String就不用mock?……不是说mock用于隔离其它对象的实现对当前对象的影响么……难道这是错的?

停停,以前写过两篇笔记,里面都用到了mock,回去看看也许能有收获,首先是这篇:[url="http://www.iteye.com/topic/200542"]写了个Servlet的测试用例,初学单元测试,大家帮我看看。[/url]

这里面的mock很自然,确实,response、request这样的对象不好创建,只能mock。那么这个servlet的下面呢?它调用的下一层是什么?没有。是的,没有。。。原来当时把下一层的调用直接给忽略掉了。那么,如果它有下一层的调用的话,该怎么办?mock吗?我又想起来以前写的另一篇曾经自以为正确的TDD过程小demo:[url]http://www.iteye.com/topic/257923[/url]

在这里,看看这个所谓的“Service”的测试代码(帖子里写的那整个过程就不看了,完全就不是那么回事):
public class BlogServiceTest extends BaseTest {

private BlogService blogService;
private BlogDAO blogDAO;

public void setBlogService(BlogService blogService){
this.blogService = blogService;
}

@Before
public void setUp(){
this.blogService = (BlogService)this.applicationContext.getBean("blogService");
blogDAO = createMock(BlogDAO.class);
this.blogService.setBlogDAO(blogDAO);
}

@After
public void tearDown(){
verify(blogDAO);
}

/**
* 测试保存BLOG
*/
@Test
public void testSaveBlog(){
Blog blog = new Blog();
blog.setTitle("title");
blog.setContent("content");
blog.setCreatedTime(new Date());

blogDAO.save(blog);

replay(blogDAO);
blogService.save(blog);
}
}


这个测试代码里对“DAO”进行了mock,为了让这个mockDAO能够工作,我又必须知道这个DAO应该调用一个save方法……等等!问题在这!这不是正在写Service的测试吗?怎么深入到DAO的接口设计中去了?测试代码本来只需要知道传什么参数给Service,并且预期测试Service返回什么值就够了,管它DAO调用什么方法干嘛?整个Service的实现对测试代码应该是不可见的。啊,原来问题在这里。我想起来TDD一书中的“可以让测试通过的[b]最小改动[/b]”,还有那个int amount=10;以及“通过建立存根(stub)来让测试程序通过编译”,我明白stub的作用了。这里需要的是stub,而不是mock。继续看之前写的这个程序,我又想起了dreamhead说的“没有逻辑的东西为什么要测试呢?”似乎都想通了。

本来晚上是通过google搜索到一篇infoQ的文章:[url="http://www.infoq.com/cn/news/2009/02/classic-mockist-tdd"]“Classic”与“Mockist”TDD,真的对立么?[/url],思考了一下,觉得自己还是没明白,于是我想写篇日志告诉自己,没有实践,看再多也没办法深切理解别人所说的东西,[b]思而不学则贻[/b],先动手做吧,在实践中学习。结果写着想着,意外收获了这些东西……

回头看看,这篇笔记好像被我写成了“散”文……匆忙记录一下,可能思考得还不够深入,也许还存在错误。嗯,再回去翻一下相关的帖子,然后动手试试吧。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值