没有合适的资源?快使用搜索试试~ 我知道了~
The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing.!
资源推荐
资源详情
资源评论













Mocks Aren't Stubs!
!
The term 'Mock Objects' has become a popular one to describe special case objects that mimic
real objects for testing. Most language environments now have frameworks that make it easy to
create mock objects. What's often not realized, however, is that mock objects are but one form of
special case test object, one that enables a different style of testing. In this article I'll explain how
mock objects work, how they encourage testing based on behavior verification, and how the
community around them uses them to develop a different style of testing.!
!
02 January 2007!
Martin Fowler!
!
Translations: French · Italian · Spanish · Portuguese · Korean ·!
Find similar articles to this by looking at these tags: popular · testing!
Contents!
!
Regular Tests!
Tests with Mock Objects!
Using EasyMock!
The Difference Between Mocks and Stubs!
Classical and Mockist Testing!
Choosing Between the Differences!
Driving TDD!
Fixture Setup!
Test Isolation!
Coupling Tests to Implementations!
Design Style!
So should I be a classicist or a mockist?!
Final Thoughts!
I first came across the term "mock object" a few years ago in the XP community. Since then I've
run into mock objects more and more. Partly this is because many of the leading developers of
mock objects have been colleagues of mine at ThoughtWorks at various times. Partly it's because I
see them more and more in the XP-influenced testing literature.!
!
But as often as not I see mock objects described poorly. In particular I see them often confused
with stubs - a common helper to testing environments. I understand this confusion - I saw them as
similar for a while too, but conversations with the mock developers have steadily allowed a little
mock understanding to penetrate my tortoiseshell cranium.!
!
This difference is actually two separate differences. On the one hand there is a difference in how
test results are verified: a distinction between state verification and behavior verification. On the
other hand is a whole different philosophy to the way testing and design play together, which I term
here as the classical and mockist styles of Test Driven Development.!
!
(In the earlier version of this essay I had realized there was a difference, but combined the two
differences together. Since then my understanding has improved, and as a result it's time to update
this essay. If you haven't read the previous essay you can ignore my growing pains, I've written this
essay as if the old version doesn't exist. But if you are familiar with the old version you may find it
helpful to note that I've broken the old dichotomy of state based testing and interaction based
testing into the state/behavior verification dichotomy and the classical/mockist TDD dichotomy. I've
also adjusted my vocabulary to match that of the Gerard Meszaros's xUnit patterns book.)!
!
Regular Tests!
!
I'll begin by illustrating the two styles with a simple example. (The example is in Java, but the
principles make sense with any object-oriented language.) We want to take an order object and fill

it from a warehouse object. The order is very simple, with only one product and a quantity. The
warehouse holds inventories of different products. When we ask an order to fill itself from a
warehouse there are two possible responses. If there's enough product in the warehouse to fill the
order, the order becomes filled and the warehouse's amount of the product is reduced by the
appropriate amount. If there isn't enough product in the warehouse then the order isn't filled and
nothing happens in the warehouse.!
!
These two behaviors imply a couple of tests, these look like pretty conventional JUnit tests.!
!
public class OrderStateTester extends TestCase {!
private static String TALISKER = "Talisker";!
private static String HIGHLAND_PARK = "Highland Park";!
private Warehouse warehouse = new WarehouseImpl();!
!
protected void setUp() throws Exception {!
warehouse.add(TALISKER, 50);!
warehouse.add(HIGHLAND_PARK, 25);!
}!
public void testOrderIsFilledIfEnoughInWarehouse() {!
Order order = new Order(TALISKER, 50);!
order.fill(warehouse);!
assertTrue(order.isFilled());!
assertEquals(0, warehouse.getInventory(TALISKER));!
}!
public void testOrderDoesNotRemoveIfNotEnough() {!
Order order = new Order(TALISKER, 51);!
order.fill(warehouse);!
assertFalse(order.isFilled());!
assertEquals(50, warehouse.getInventory(TALISKER));!
}!
xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown. In this case the
setup phase is done partly in the setUp method (setting up the warehouse) and partly in the test
method (setting up the order). The call to order.fill is the exercise phase. This is where the object is
prodded to do the thing that we want to test. The assert statements are then the verification stage,
checking to see if the exercised method carried out its task correctly. In this case there's no explicit
teardown phase, the garbage collector does this for us implicitly.!
!
During setup there are two kinds of object that we are putting together. Order is the class that we
are testing, but for Order.fill to work we also need an instance of Warehouse. In this situation Order
is the object that we are focused on testing. Testing-oriented people like to use terms like object-
under-test or system-under-test to name such a thing. Either term is an ugly mouthful to say, but as
it's a widely accepted term I'll hold my nose and use it. Following Meszaros I'll use System Under
Test, or rather the abbreviation SUT.!
!
So for this test I need the SUT (Order) and one collaborator (warehouse). I need the warehouse for
two reasons: one is to get the tested behavior to work at all (since Order.fill calls warehouse's
methods) and secondly I need it for verification (since one of the results of Order.fill is a potential
change to the state of the warehouse). As we explore this topic further you'll see there we'll make a
lot of the distinction between SUT and collaborators. (In the earlier version of this article I referred
to the SUT as the "primary object" and collaborators as "secondary objects")!
!
This style of testing uses state verification: which means that we determine whether the exercised
method worked correctly by examining the state of the SUT and its collaborators after the method
was exercised. As we'll see, mock objects enable a different approach to verification.!
!
Tests with Mock Objects!
剩余11页未读,继续阅读
资源评论


navyxu_cn
- 粉丝: 0
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助


最新资源
- 试卷、试题—--2011年至2013年计算机基础与程序设计考题及答案全集(1).doc
- 软件工程毕业设计-基于android系统的魅力城乡旅游助手软件(1).doc
- PHP书城系统用户模块的设计与实现(1).docx
- 通信光缆工程作业指导书..模板(1).doc
- 2022年计算机系统配套用各种消耗品行业洞察报告及未来五至十年预测分析报告(1).docx
- 最新网站合同纠纷(十五篇)(1).docx
- 会计实用EXCEL秘技(二)【推荐文章】(1).doc
- 软件研发人员绩效考核激励方案(草稿)(1).doc
- 数信学院图书管理系统的设计--大学毕业设计论文(1).doc
- 软件工程相关术语(1).docx
- 计算机网络复习概要市公开课一等奖省赛课微课金奖课件(1).pptx
- 基于plc全自动洗衣机系统设计本科论文(1)(1).doc
- 大数据背景下大学生网络信息消费探究(1).docx
- Java程序设计任务驱动式教程05章(1).pptx
- 互联网时代下的人力资源管理新思维探讨(1).docx
- 软件工作计划-(荟萃20篇)(1).doc
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈



安全验证
文档复制为VIP权益,开通VIP直接复制
