Why You Should Write Unit Tests – Testing Techniques 8

Roger HughesDecember 8th, 2011Last Updated: October 21st, 2012

0 48 4 minutes read

I’ve had lots of reaction to my recent blog on ‘What you Should Test’, some agreeing with me for varying reasons and others thinking that I’m totally dangerous for suggesting that certain classes may not need unit tests. Having dealt with What to test, today’s blog deals with Why you should write unit tests, and today’s example code is based upon a true story: only names, dates and facts have been changed.

A client recently asked for a emergency release of some code to display a message on the screen, for legal reasons, on appropriate pages of their web site.

The scenario was that a piece of information should be displayed on the screen if it existed in the database – a very simple scenario, which can be covered by a few simple lines of code. However, in the rush to write the code, the developer didn’t write any unit tests and the code contained a bug that wasn’t spotted until the patch reached UAT. You may ask what the bug was, and it was something that we’ve all done at some point in our careers: adding an unwanted semi-colon ‘;’ to the end of a line.

I’m going to demonstrate a re-written, stunt double, version of the code using my AddressService scenario that I’ve used in my previous ‘Testing Techniques’ blogs as outlined by the UML diagram below:

In this demonstration the functionality has changed, but the logic and sample code structure has essentially remained the same. In the AddressService world, the logic runs like this:

Get an address from the database.
If the address exists then format it and return the resulting string.
If the addres does not exist then return null.
If the formatting fails, don’t worry about it and return null.

The re-written AddressService.findAddress(…) looks something like this:

@Component
public class AddressService {

  private static final Logger logger = LoggerFactory
      .getLogger(AddressService.class);

  private AddressDao addressDao;

  public String findAddressText(int id) {

    logger.info("In Address Service with id: " + id);
    Address address = addressDao.findAddress(id);

    String formattedAddress = null;

    if (address != null);
    try {
      formattedAddress = address.format();
    } catch (AddressFormatException e) {
      // That's okay in this business case so ignore it
    }

    logger.info("Leaving Address Service with id: " + id);
    return formattedAddress;
  }

  @Autowired
  @Qualifier("addressDao")
  void setAddressDao(AddressDao addressDao) {
    this.addressDao = addressDao;
  }
}

Did you spot the bug? I didn’t when I reviewed the code… Just in case, I’ve annotated a screen shot below:

The point of demonstrating a trivial bug, a simple mistake that anyone can make, is to highlight the importance of writing a few unit tests because unit tests would have spotted the problem and saved a whole load of time and expense. Of course, each organisation is different, but releasing the above code caused the following sequence of events:

The application is deployed to Dev, Test, and UAT.
The test team checked that the modified screen works okay and passes the change.
Other screens are regression tested and found to be incorrect. All failing screens are noted.
An urgent bug report is raised.
The report passes through various management levels.
The report gets passed to me (and I miss lunch) to investigate the possible problem.
The report gets sent to three other members of the team to investigate (four pairs of eyes are better than one)
The offending semi-colon is found and fixed.
The code is retested in dev and checked in to source control.
The application is built and deployed to Dev, Test, and UAT.
The test team checks that the modified screen works okay and passes the change.
Other screens are regression tested and pass.
The emergency fix is passed.

The above chain of events obviously wastes a good number of man hours, costs a shed load of cash, unnecessarily raises peoples stress levels, and tarnishes our reputation with the customer: all of which are very good reasons for writing unit tests.

To prove the point, I’ve written the three missing unit tests and it only took me an extra 15 minutes development time, which compared with the number of man hours wasted seems a good use of developer time.

@RunWith(UnitilsJUnit4TestClassRunner.class)
public class WhyToTestAddressServiceTest {

  private AddressService instance;

  @Mock
  private AddressDao mockDao;

  @Mock
  private Address mockAddress;

  /**
   * @throws java.lang.Exception
   */
  @Before
  public void setUp() throws Exception {

    instance = new AddressService();
    instance.setAddressDao(mockDao);
  }

  /**
   * This test passes with the bug in the code
   * 
   * Scenario: The Address object is found in the database and can return a
   * formatted address
   */
  @Test
  public void testFindAddressText_Address_Found() throws AddressFormatException {

    final int id = 1;
    expect(mockDao.findAddress(id)).andReturn(mockAddress);
    expect(mockAddress.format()).andReturn("This is an address");

    replay();
    instance.findAddressText(id);
    verify();
  }

  /**
   * This test fails with the bug in the code
   * 
   * Scenario: The Address Object is not found and the method returns null
   */
  @Test
  public void testFindAddressText_Address_Not_Found() throws AddressFormatException {

    final int id = 1;
    expect(mockDao.findAddress(id)).andReturn(null);

    replay();
    instance.findAddressText(id);
    verify();
  }

  /**
   * This test passes with the bug in the code
   * 
   * Scenario: The Address Object is found but the data is incomplete and so a
   * null is returned.
   */
  @Test
  public void testFindAddressText_Address_Found_But_Cant_Format() throws AddressFormatException {

    final int id = 1;
    expect(mockDao.findAddress(id)).andReturn(mockAddress);
    expect(mockAddress.format()).andThrow(new AddressFormatException());

    replay();
    instance.findAddressText(id);
    verify();
  }
}

And finally,at the risk of sounding smug I have to confess that although in this case, the bug wasn’t mine, I have released similar bugs into the wild in the past – before I learnt to write unit tests…
The source code is available from GitHub at:

git://github.com/roghughe/captaindebug.git

Reference: Why You Should Write Unit Tests – Testing Techniques 8 from our JCG partner Roger Hughes at the Captain Debug’s Blog.

Related Articles :