分享一份自己编写的easymock的教程

这个说到点上了，我一直喜欢在team中强调，单元测试的案例不好写，easymock不好用，归根到底都是自己的代码造成的。因为代码自身的问题造成测试困难，解决的方法是通过重构来优化代码，而不是找另一个强大的mock工具来干easymock干不了的事情。

解决问题的正确途径是学会如何编写测试友好的代码，而不是如何使用mock框架来达到目的。

正是出于这个考虑，所以我坚持在有mockito和jmockit这样功能更加强大的mock框架可以选择的情况下，依然希望能尽量在easymock的能力范围内搞定问题，甚至对于一些做法不是很好胆识easymock也能支持的功能，我都在教程中反复强调：这种用法只是权宜之计，重构才是王道。

再厚着脸皮“自夸”一下，在决定写这个教程之前，我曾通过google大法找到了很多easyock介绍性的文章和一些教程，找到很多内容，但是一般都讲解的不是很全面很系统。我也曾打算是整理一个教程列表share给team中队easymock不大熟悉的同事,但是最后发现没有合适的.

比较接近要求的是easymock自带的document，但是还是不够细致，很多特性只是告诉读者有这个东西，或者给了一个简单的范例。对于我这种对单元测试还有mock框架比较熟悉的人来说，这点内容足够我了解easymock的使用。但是对于新手，他们未必能理解这个特性后面的东西。

所以才花费时间编写了这个教程，基本的出发点对针对对easymoc乃至unit test都不大熟悉和理解的新人，希望能对他们有所帮助。

感谢楼上几位的支持，让我有一点欣慰的感觉。谢谢！

写的不错，很系统。

之前几乎不用这个，感觉不是太踏实，反而更喜欢用fake数据库（如HSQLDB）来干，感觉更真实可靠

不知道基于spring autowired的怎么做mock/stub较好，同样加上一堆@Component的stubs，然后context-scan?

dao可以用hsqldb来作
但service最好还是用mock来作
不然作数据有点复杂的说.

感觉还是对测试的范围定义有所不同，对于unit test，肯定是只能使用mock和stub，因为以unit test的视角来看，测试的对象仅仅是当前这一个unit，通常是一个类，其他的应该都不在测试范围之类，对于这个测试类的诸多依赖，我们假定他们是通过他们自己的unit test类来保证是可靠的。这样我们只要通过mock/stub来模拟依赖的行为并测试这些行为下我们关注的测试对象的行为是否符合要求即可。

这个是我对unit test的测试范围认定。我认为在unit test阶段应该保证所有类在排除外界影响的情况下可以正常工作。

然后再unit test之上才是诸如component test, system test等其他的测试案例，这些测试案例才会运行这个系统(或者系统的一部分模块)并提供需要的运行环境如数据库，网络等。fake应该是在这个阶段引入。典型如使用内嵌数据库来模拟mysql,oracle然后用dbunit初始化数据再运行我们的系统来测试是否工作正常。

感觉在unit test阶段和component test, system test阶段，测试的目的是不同的。举个例子说，如果将系统比喻为一台机器，unit test是保证这个机器的每个部件都满足要求，而component test, system test是保证这些单个功能都OK的部件组合起来之后还是能工作正常。

下午看了楼主写的文章非常好！把一些概念讲得很清楚

给楼主投了精华，表示对分享精神的敬意

谢谢！

你说的是jMock吧？我只劝说过人把jmock换成mockito, 这个见仁见智了

jmock, mockito, jmockit

这是三个完全不同的东西，google一下就知道了。

支持LZ，总结教程是利己利人的工作。