Previous | Next |
insertOrder
method of PetStoreImpl
.
As we have already seen, insertOrder
calls OrderDao
and then ItemDao
.
PetStoreImpl (excerpt)
public class PetStoreImpl implements PetStoreFacade, OrderService { private ItemDao<Item> itemDao; private OrderDao<Order> orderDao; /* other methods and members omitted */ public void insertOrder(Order order) { this.orderDao.insertOrder(order); this.itemDao.updateQuantity(order); } }
PetStoreImplTest.xml
demonstrates how to create mocks using Spring bean configuration
with a static factory method.
PetStoreImplTest.xml (excerpt)
<beans> <bean id="itemDao" class="org.easymock.EasyMock" factory-method="createMock" singleton="false"> <constructor-arg> <bean class="java.lang.Class" factory-method="forName"> <constructor-arg><value>org.springunit.framework.samples.jpetstore.dao.ItemDao</value></constructor-arg> </bean> </constructor-arg> </bean> <bean id="orderDao" class="org.easymock.EasyMock" factory-method="createMock" singleton="false"> <constructor-arg> <bean class="java.lang.Class" factory-method="forName"> <constructor-arg><value>org.springunit.framework.samples.jpetstore.dao.OrderDao</value></constructor-arg> </bean> </constructor-arg> </bean> <!-- other beans omitted --> </beans>
subject
and the input order
from the SpringUnit context.
References to each of the DAOs are obtained from
the subject
and stored in an array.
Now, the expected behavior of the mocks is
established, calling insertOrder
first on the orderDao
,
then updateQuantity
on itemDao
.
The call to replayMocks
tells the EasyMock framework that all mocked behavior
has been coded.
Next, the test calls the method under test, insertOrder
,
and then verifyMocks
.
verifyMocks
checks that the behavior exhibited
by the call to insertOrder
matches the expected behavior programmed above.
PetStoreImplTest.java (excerpt)
public void testInsertOrder() throws Exception { PetStoreImpl subject = getObject("subject"); Order order = getObject("order"); ItemDao<Item> itemDao = subject.getItemDao(); OrderDao<Order> orderDao = subject.getOrderDao(); Object[] mocks = new Object[]{itemDao, orderDao}; orderDao.insertOrder(order); itemDao.updateQuantity(order); EasyMock.replay(mocks); subject.insertOrder(order); EasyMock.verify(mocks); }
Finally, here are elements of the Spring configuration file
that are relevant to this test.
First, notice how the mocked DAOs are wired to the subject
.
Next, note carefully how the subject
is declared in the
scope where singleton="false"
.
This causes every subsequent reference within this file to cause
the generation at run-time of a new instance of PetStoreImpl
.
Finally, see how the subject
and order
are declared in the scope for this test.
Notice that order
reuses a test data value
from OrderData.xml
: order1
is a non-singleton instance of an Order
object.
PetStoreImplTest.xml (excerpt)
<beans> <bean id="subject" class="org.springunit.framework.samples.jpetstore.domain.logic.PetStoreImpl" singleton="false"> <property name="itemDao"> <ref local="itemDao"/> </property> <property name="orderDao"> <ref local="orderDao"/> </property> <!-- similarly for other DAOs --> </bean> <import resource="classpath:OrderData.xml"/> <!-- order1 comes from here --> <!-- other imports omitted --> <bean id="petStoreImplTest" class="org.springunit.framework.SpringUnitContext"> <property name="data"> <map> <entry key="testInsertOrder"> <map> <entry key="subject"> <ref local="subject"/> </entry> <entry key="order"> <ref bean="order1"/> </entry> </map> </entry> <!-- other entries omitted --> </map> </property> </bean> <!-- other beans omitted --> </beans>
Previous | Next |