{"id":768,"date":"2011-12-08T10:22:00","date_gmt":"2011-12-08T10:22:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/why-you-should-write-unit-tests-testing-techniques-8.html"},"modified":"2012-10-21T20:53:54","modified_gmt":"2012-10-21T20:53:54","slug":"why-you-should-write-unit-tests-testing","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/12\/why-you-should-write-unit-tests-testing.html","title":{"rendered":"Why You Should Write Unit Tests – Testing Techniques 8"},"content":{"rendered":"
I\u2019ve had lots of reaction to my recent blog on \u2018What you Should Test\u2019, some agreeing with me for varying reasons and others thinking that I\u2019m totally dangerous for suggesting that certain classes may not need unit tests. Having dealt with What<\/i> to test, today\u2019s blog deals with Why<\/i> you should write unit tests, and today\u2019s example code is based upon a true story: only names, dates and facts have been changed.<\/p>\n

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.<\/p>\n

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\u2019t write any unit tests and the code contained a bug that wasn\u2019t spotted until the patch reached UAT. You may ask what the bug was, and it was something that we\u2019ve all done at some point in our careers: adding an unwanted semi-colon \u2018;\u2019 to the end of a line.<\/p>\n

I\u2019m going to demonstrate a re-written, stunt double, version of the code using my AddressService<\/span> scenario that I\u2019ve used in my previous \u2018Testing Techniques\u2019 blogs as outlined by the UML diagram below:<\/p>\n

<\/a><\/div>\n

In this demonstration the functionality has changed, but the logic and sample code structure has essentially remained the same. In the AddressService <\/span>world, the logic runs like this:<\/p>\n

    \n
  1. Get an address from the database.<\/li>\n
  2. If the address exists then format it and return the resulting string.<\/li>\n
  3. If the addres does not exist then return null.<\/li>\n
  4. If the formatting fails, don\u2019t worry about it and return null.<\/li>\n<\/ol>\n

    The re-written AddressService.findAddress(…) <\/span>looks something like this:<\/p>\n

    @Component\r\npublic class AddressService {\r\n\r\n  private static final Logger logger = LoggerFactory\r\n      .getLogger(AddressService.class);\r\n\r\n  private AddressDao addressDao;\r\n\r\n  public String findAddressText(int id) {\r\n\r\n    logger.info(\"In Address Service with id: \" + id);\r\n    Address address = addressDao.findAddress(id);\r\n\r\n    String formattedAddress = null;\r\n\r\n    if (address != null);\r\n    try {\r\n      formattedAddress = address.format();\r\n    } catch (AddressFormatException e) {\r\n      \/\/ That's okay in this business case so ignore it\r\n    }\r\n\r\n    logger.info(\"Leaving Address Service with id: \" + id);\r\n    return formattedAddress;\r\n  }\r\n\r\n  @Autowired\r\n  @Qualifier(\"addressDao\")\r\n  void setAddressDao(AddressDao addressDao) {\r\n    this.addressDao = addressDao;\r\n  }\r\n}\r\n<\/pre>\n
    Did you spot the bug? I didn\u2019t when I reviewed the code… Just in case, I\u2019ve annotated a screen shot below:
     
    <\/div> <\/div><\/p>\n
    \n<\/div>\n
    <\/a><\/div>\n
    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:<\/p>\n