Page 169 -
P. 169

public void testDuplicateReference( ) {
                                Account accounts[] = new Account[3];
                                accounts[0] = new Account( );
                                accounts[0].principal = 35;
                                accounts[0].rate = (float) .04;
                                accounts[0].daysActive = 365;
                                accounts[0].accountType = Account.PREMIUM;

                                accounts[1] = accounts[0];
                                accounts[2] = new Account( );
                                accounts[2].principal = 50;
                                accounts[2].rate = (float) .04;
                                accounts[2].daysActive = 600;
                                accounts[2].accountType = Account.PREMIUM_PLUS;

                                float result = feeCalculation.calculateFee(accounts);
                                assertEquals(result, 0.0781316, 0.000001);
                            }
                          It’s also possible to create tests that are expected to fail. The programmer expects
                          calculateFee( ) to choke on one particular boundary condition—being passed null instead
                          of an array:
                            public void testNullInput( ) {
                                Account accounts[] = null;
                                float result = feeCalculation.calculateFee(accounts);
                                assertTrue(true);
                            }
                          The assertion assertTrue(true) will never fail. It’s included for the benefit of any program-
                          mer reading this unit test. It shows that the test is expected to get to this line. Unfortu-
                          nately, calculateFee throws a NullPointerException error.
                          In this case, that’s exactly the behavior that the programmer expects. The unit test can be
                          altered to show that it expects the call to calculateFee( ) to fail:
                            public void testNullInput( ) {
                                Account accounts[] = null;
                                try {

                                    float result = feeCalculation.calculateFee(accounts);
                                    fail( );
                                } catch (NullPointerException e) {
                                    assertTrue(true);
                                }
                            }
                          The fail( ) assertion is placed after calculateFee( ) to verify that it throws an exception and
                          never executes the next statement. The assertTrue(true) assertion is then used to show
                          that the call is expected to throw a specific error, and the test expects to catch it.
                          These test methods by no means represent an exhaustive test case for the FeeCalculation
                          class. But even this limited set of tests is enough, for instance, to ensure that a refactoring
                          has not broken the behavior of the class. It would not take a programmer much longer to
                          come up with a more exhaustive test case for this example.
                                                                                  DESIGN AND PROGRAMMING  161
   164   165   166   167   168   169   170   171   172   173   174