The Mock Class


You don't have the actual JimBobAch class, but you can create a mock class that implements the same Ach interface as the JimBobAch class. Your test will work with this mock object.

The MockAch class below implements the Ach interface. The only ACH service that concerns you for now is the issueDebit method; you implement the other methods as stubs, returning null to satisfy the compiler. You code the issueDebit method to ensure that the parameters passed to it are as expected. If the parameters are valid,[2] you construct an AchResponse object, populating it with the data that the test expects to see.

[2] You should also ensure that the AchCredentials object is as expected; I'm omitting the check here because of space considerations.

 package sis.studentinfo; import java.util.*; import com.jimbob.ach.*; import junit.framework.Assert; class MockAch implements Ach {    public AchResponse issueDebit(          AchCredentials credentials, AchTransactionData data) {       Assert.assertTrue(          data.account.equals(AccountTest.ACCOUNT_NUMBER));       Assert.assertTrue(data.aba.equals(AccountTest.ABA));       AchResponse response = new AchResponse();       response.timestamp = new Date();       response.traceCode = "1";       response.status = AchStatus.SUCCESS;       return response;    }    public AchResponse markTransactionAsNSF(AchCredentials credentials,          AchTransactionData data,          String traceCode) {       return null;    }    public AchResponse refundTransaction(AchCredentials credentials,          AchTransactionData data,          String traceCode) {       return null;    }    public AchResponse issueCredit(AchCredentials credentials,          AchTransactionData data) {       return null;    }    public AchResponse voidSameDayTransaction(          AchCredentials credentials,          AchTransactionData data,          String traceCode) {       return null;    }    public AchResponse queryTransactionStatus(AchCredentials credentials,          AchTransactionData data, String traceCode) {       return null;    } } 

Note that this solution creates a two-way dependency, as shown in Figure 12.1. AccountTest class creates MockAch, meaning the test class is dependent upon MockAch. MockAch is dependent upon AccountTest since MockAch refers to the ACCOUNT_NUMBER and ABA class constants from AccountTest. Two-way dependencies are generally not a good thing, but in some cases such a tight coupling is acceptable. The test requires the mock, and the mock is useful only in close concert with the test.

Figure 12.1. Mocking the Ach Interface


Now back to testTransferFromBank. In it, you originally wrote code to instantiate the nonexistent JimBobAch class. Instead, you can now create a MockAch instance and pass that into the Account object:

 public void testTransferFromBank() {    // acount.setAch(new com.jimbob.ach.JimBobAch());    account.setAch(new MockAch());    final BigDecimal amount = new BigDecimal("50.00");    account.transferFromBank(amount);    assertEquals(amount, account.getBalance()); } 



Agile Java. Crafting Code with Test-Driven Development
Agile Javaв„ў: Crafting Code with Test-Driven Development
ISBN: 0131482394
EAN: 2147483647
Year: 2003
Pages: 391
Authors: Jeff Langr

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net