Using the Domain Model pattern - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 81

The test for the first scenario calls updateDeliveryInfo() with valid delivery infor-
mation and verifies that it updates PendingOrder . Each of the tests for the other sce-
nario calls updateDeliveryInfo() with invalid delivery information and verifies
that it returns an error code and leaves the PendingOrder unchanged. When doing
test-driven development we write tests for each of these scenarios and use them to
drive the design of PlaceOrderService . Let's look at the test for the first scenario.

Writing a test
Listing 3.2 shows a JUnit-based test case for the successful scenario. This test case
calls updateDeliveryInfo() with valid delivery information and verifies that it
returns the expected result. Because it is a unit test, it doesn't need to use Spring
to construct the service. It simply instantiates PlaceOrderServiceImpl using new ,
invokes a method, and verifies that it returns the correct result.

Listing 3.2 The valid delivery information test case

public class PlaceOrderServiceTests extends TestCase {

private PlaceOrderService service;

B Creates
PlaceOrderServiceImpl

public void setUp() throws Exception {
service = new PlaceOrderServiceImpl();
}

public void testUpdateDeliveryInfo_Valid() throws Exception {
Address deliveryAddress =
makeGoodDeliveryAddress();
Date deliveryTime = makeGoodDeliveryTime();

C Creates
test data

String pendingOrderId = null;

PlaceOrderServiceResult result =
service.updateDeliveryInfo(
pendingOrderId,
deliveryAddress,
deliveryTime);

D Calls the
service

PendingOrder pendingOrder = result.getPendingOrder();

assertTrue(result.isSuccess());
assertEquals(
deliveryAddress,
pendingOrder.getDeliveryAddress());
assertEquals(deliveryTime,
pendingOrder.getDeliveryTime());
}

E Verifies the
outcome