Lives in the UK. Likes blogging, cycling and eating lemon drizzle cake. Roger is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Why You Should Write Unit Tests - Testing Techniques 8

12.08.2011
| 4083 views |
  • submit to reddit
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:
  1. Get an address from the database.
  2. If the address exists then format it and return the resulting string.
  3. If the addres does not exist then return null.
  4. 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

 

From http://www.captaindebug.com/2011/12/why-you-should-write-unit-tests-testing.html

Published at DZone with permission of Roger Hughes, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

John David replied on Thu, 2012/01/26 - 3:08am

I think every class and every line of code should be well tested and have written test cases to cover all the use cases.

There is no reason that we should not test any class for any reason. Testing must be for every part of the code.

Java Eclipse

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.