Why You Should Write Unit Tests – Testing Techniques 8

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

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

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


− five = 1



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close