{"id":677,"date":"2011-11-22T16:41:00","date_gmt":"2011-11-22T16:41:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/regular-unit-tests-and-stubs-testing-techniques-4.html"},"modified":"2012-10-21T20:37:42","modified_gmt":"2012-10-21T20:37:42","slug":"regular-unit-tests-and-stubs-testing","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/11\/regular-unit-tests-and-stubs-testing.html","title":{"rendered":"Regular Unit Tests and Stubs – Testing Techniques 4"},"content":{"rendered":"
My last blog was the third in a series of blogs on approaches to testing code and discussing what you do and don\u2019t have to test. It\u2019s based around my simple scenario of retrieving an address from a database using a very common pattern:<\/p>\n
<\/a><\/div>\n

…and I proffered the idea that any class that doesn\u2019t contain any logic doesn\u2019t really need unit testing. In this I included my data access object, DAO, preferring instead to integration test this class to ensure it worked in collaboration with the database.<\/p>\n

Today\u2019s blog covers writing a regular or classical unit test that enforces test subject isolation using stub objects. The code we\u2019ll be testing is, again, the AddressService<\/strong>:<\/p>\n

@Component\r\npublic class AddressService {\r\n\r\n  private static final Logger logger = LoggerFactory.getLogger(AddressService.class);\r\n\r\n  private AddressDao addressDao;\r\n\r\n  \/**\r\n   * Given an id, retrieve an address. Apply phony business rules.\r\n   * \r\n   * @param id\r\n   *            The id of the address object.\r\n   *\/\r\n  public Address findAddress(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    address = businessMethod(address);\r\n\r\n    logger.info(\"Leaving Address Service with id: \" + id);\r\n    return address;\r\n  }\r\n\r\n  private Address businessMethod(Address address) {\r\n\r\n    logger.info(\"in business method\");\r\n\r\n    \/\/ Apply the Special Case Pattern (See MartinFowler.com)\r\n    if (isNull(address)) {\r\n      address = Address.INVALID_ADDRESS;\r\n    }\r\n\r\n    \/\/ Do some jiggery-pokery here....\r\n\r\n    return address;\r\n  }\r\n\r\n  private boolean isNull(Object obj) {\r\n    return obj == null;\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
Michael Feather\u2019s book Working Effectively with Legacy Code states that a test is not a unit test if:<\/p>\n
    \n
  1. It talks to a database.<\/li>\n
  2. It communicates across a network.<\/li>\n
  3. It touches the file system.<\/li>\n
  4. You have to do special things to your environment (such as editing configuration files) to run it.<\/li>\n<\/ol>\n
    To uphold these rules, you need to isolate your object under test from the rest of your system, and that\u2019s where stub objects come in. Stub objects are objects that are injected into your object and are used to replace real objects in test situations. Martin Fowler defines stubs, in his essay Mocks Aren\u2019t Stubs<\/a> as:<\/p>\n
    \u201cStubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’\u201d.
     
    <\/div> <\/div><\/p>\n
    Picking a word to describe stubs is very difficult, I could choose dummy or fake, but there are types of replacement object that are known as dummies or fakes – also described by Martin Fowler:<\/span><\/p>\n