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 :

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

Leave a Reply


× nine = 54



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
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.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books