Software Development Cross Solution - Index of - Free

}
test-driven development
// Tell our test framework what to call, and what to expect
EasyMock.expect(mockAccessor.getGC(12345)).andReturn(startGC);
// Simulate processing an order
mockAccessor.saveOrder(orderInfo);
// Then the processor should call saveGC(...) with an empty GC
mockAccessor.saveGC(endGC);
// And nothing else should get called on our mock.
EasyMock.replay(mockAccessor);
// Create an OrderProcessor...
OrderProcessor processor = new OrderProcessor();
processor.setDBAccessor(mockAccessor);
Receipt rpt = processor.processOrder(orderInfo);
// Validate receipt...
Once you create a mock object, it’s in “record
mode.” That means you tell it what to expect and
what to do...so when you put it in replay mode,
and your tests use it, you’ve set up exactly what
the mock object should do.
First, expect a call to getGC() with the value
12345... that matches up with the orderInfo
object we created over here.
This might seem like a good bit of work
here, but we’ve saved one class. Add in
all the other variations of testing for
specific gift card things, and you’ll save
lots of classes...and that’s a big deal.
Download at WoweBook.Com
Remember, you
haven’t had to
write your own
class... that’s
the big win here.
When getGC() is called with that
value, return the startGC object... this
simulates getting a card from the
database, and we’ve supplied the exact
values we want for this test scenario.
This doesn’t do anything...but it tells the mock
object that you should have saveOrder() called, with
orderInfo as the parameter. Otherwise, something’s
gone wrong, and it should throw an exception.
Then, the mock object should have saveGC() called on it, with the
endGC gift card simulating the right amount of money being spent.
If this isn’t called, with these values, then the test should fail.
Calling replay() tells the mock object
framework “OK, something is going to
replay these activities, so get ready.” This is like
activating the
object; it’s ready
to be used now.
And here’s where we use the mock
object as a stand-in for a DBAccessor
implementation: we test order processing,
never having to write a custom
implementation for this particular test
case (or for any of the other specific
test cases we need to check out).
you are here 4 307