{"id":680,"date":"2011-11-21T10:20:00","date_gmt":"2011-11-21T10:20:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/what-should-you-unit-test-testing-techniques-3.html"},"modified":"2012-10-21T20:38:17","modified_gmt":"2012-10-21T20:38:17","slug":"what-should-you-unit-test-testing","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/11\/what-should-you-unit-test-testing.html","title":{"rendered":"What Should you Unit Test? – Testing Techniques 3"},"content":{"rendered":"
I was in the office yesterday, talking about testing to one of my colleagues who was a little unconvinced by writing unit tests.<\/p>\n

One of the reasons that he was using was that some tests seem meaningless, which brings me on the the subject of what exactly you unit test, and what you don\u2019t need to bother with.<\/p>\n

Consider a simple immutable Name bean below with a constructor and a bunch of getters.<\/p>\n

In this example I\u2019m going to let the code speak for itself as I hope that it\u2019s obvious that any testing would be pointless.<\/p>\n

public class Name {\r\n\r\n  private final String firstName;\r\n  private final String middleName;\r\n  private final String surname;\r\n\r\n  public Name(String christianName, String middleName, String surname) {\r\n    this.firstName = christianName;\r\n    this.middleName = middleName;\r\n    this.surname = surname;\r\n  }\r\n\r\n  public String getFirstName() {\r\n    return firstName;\r\n  }\r\n\r\n  public String getMiddleName() {\r\n    return middleName;\r\n  }\r\n\r\n  public String getSurname() {\r\n    return surname;\r\n  }\r\n}\r\n<\/pre>\n
…and just to underline the point, here is the pointless test code:<\/p>\n
public class NameTest {\r\n\r\n  private Name instance;\r\n\r\n  @Before\r\n  public void setUp() {\r\n    instance = new Name(\"John\", \"Stephen\", \"Smith\");\r\n  }\r\n\r\n  @Test\r\n  public void testGetFirstName() {\r\n    String result = instance.getFirstName();\r\n    assertEquals(\"John\", result);\r\n  }\r\n\r\n  @Test\r\n  public void testGetMiddleName() {\r\n    String result = instance.getMiddleName();\r\n    assertEquals(\"Stephen\", result);\r\n  }\r\n\r\n  @Test\r\n  public void testGetSurname() {\r\n    String result = instance.getSurname();\r\n    assertEquals(\"Smith\", result);\r\n  }\r\n}\r\n<\/pre>\n
The reason it\u2019s pointless testing this class is that the code doesn\u2019t contain any logic; however, the moment you add something like this to the Name class:<\/p>\n
public String getFullName() {\r\n\r\n    if (isValidString(firstName) && isValidString(middleName) && isValidString(surname)) {\r\n      return firstName + \" \" + middleName + \" \" + surname;\r\n    } else {\r\n      throw new RuntimeException(\"Invalid Name Values\");\r\n    }\r\n  }\r\n\r\n  private boolean isValidString(String str) {\r\n    return isNotNull(str) && str.length() > 0;\r\n  }\r\n\r\n  private boolean isNotNull(Object obj) {\r\n    return obj != null;\r\n  }\r\n<\/pre>\n
…then the whole situation changes. Adding some logic in the form of an if statement generates a whole bunch of tests:<\/p>\n
@Test\r\n  public void testGetFullName_with_valid_input() {\r\n\r\n    instance = new Name(\"John\", \"Stephen\", \"Smith\");\r\n\r\n    final String expected = \"John Stephen Smith\";\r\n\r\n    String result = instance.getFullName();\r\n    assertEquals(expected, result);\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_null_firstName() {\r\n\r\n    instance = new Name(null, \"Stephen\", \"Smith\");\r\n    instance.getFullName();\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_null_middleName() {\r\n\r\n    instance = new Name(\"John\", null, \"Smith\");\r\n    instance.getFullName();\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_null_surname() {\r\n\r\n    instance = new Name(\"John\", \"Stephen\", null);\r\n    instance.getFullName();\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_no_firstName() {\r\n\r\n    instance = new Name(\"\", \"Stephen\", \"Smith\");\r\n    instance.getFullName();\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_no_middleName() {\r\n\r\n    instance = new Name(\"John\", \"\", \"Smith\");\r\n    instance.getFullName();\r\n  }\r\n\r\n  @Test(expected = RuntimeException.class)\r\n  public void testGetFullName_with_no_surname() {\r\n\r\n    instance = new Name(\"John\", \"Stephen\", \"\");\r\n    instance.getFullName();\r\n  }\r\n<\/pre>\n
So, given that I\u2019ve just said that you shouldn’t need to test objects that do not contain any logic statements, and in a list of logic<\/i> statements<\/i> I\u2019d include if and switch<\/strong> together with all the operators (+-*-), and a whole bundle of things that could change and objects state.
 
<\/div> <\/div><\/p>\n
Given this premise, I\u2019d then suggest that it\u2019s pointless writing a unit test for the address data access object (DAO) in the Address<\/a> project I\u2019ve been talking about in my last couple of blogs. The DAO is defined by the AddressDao<\/strong> interface and implemented by the JdbcAddress<\/strong> class:<\/p>\n
public class JdbcAddress extends JdbcDaoSupport implements AddressDao {\r\n\r\n  \/**\r\n   * This is an instance of the query object that'll sort out the results of\r\n   * the SQL and produce whatever values objects are required\r\n   *\/\r\n  private MyQueryClass query;\r\n\r\n  \/** This is the SQL with which to run this DAO *\/\r\n  private static final String sql = \"select * from addresses where id = ?\";\r\n\r\n  \/**\r\n   * A class that does the mapping of row data into a value object.\r\n   *\/\r\n  class MyQueryClass extends MappingSqlQuery<address> {\r\n\r\n    public MyQueryClass(DataSource dataSource, String sql) {\r\n      super(dataSource, sql);\r\n      this.declareParameter(new SqlParameter(Types.INTEGER));\r\n    }\r\n\r\n    \/**\r\n     * This the implementation of the MappingSqlQuery abstract method. This\r\n     * method creates and returns a instance of our value object associated\r\n     * with the table \/ select statement.\r\n     * \r\n     * @param rs\r\n     *            This is the current ResultSet\r\n     * @param rowNum\r\n     *            The rowNum\r\n     * @throws SQLException\r\n     *             This is taken care of by the Spring stuff...\r\n     *\/\r\n    @Override\r\n    protected Address mapRow(ResultSet rs, int rowNum) throws SQLException {\r\n\r\n      return new Address(rs.getInt(\"id\"), rs.getString(\"street\"),\r\n          rs.getString(\"town\"), rs.getString(\"post_code\"),\r\n          rs.getString(\"country\"));\r\n    }\r\n  }\r\n\r\n  \/**\r\n   * Override the JdbcDaoSupport method of this name, calling the super class\r\n   * so that things get set-up correctly and then create the inner query\r\n   * class.\r\n   *\/\r\n  @Override\r\n  protected void initDao() throws Exception {\r\n    super.initDao();\r\n    query = new MyQueryClass(getDataSource(), sql);\r\n  }\r\n\r\n  \/**\r\n   * Return an address object based upon it's id\r\n   *\/\r\n  @Override\r\n  public Address findAddress(int id) {\r\n    return query.findObject(id);\r\n  }\r\n\r\n}\r\n<\/pre>\n
In the code above, the only method in the interface is:<\/p>\n
@Override\r\n  public Address findAddress(int id) {\r\n    return query.findObject(id);\r\n  }\r\n<\/pre>\n
…which is really a simple getter method. This seems okay to me as there really should not be any business logic in a DAO, that belongs in the AddressService<\/strong>, which should have a plentiful supply of unit tests.<\/p>\n
You may want to make a decision on whether or not you want to write unit tests for the MyQueryClass. To me this is a borderline case, so I look forward to any comments…<\/span><\/p>\n
I\u2019m guessing that someone will disagree with this approach, say you should test the JdbcAddress<\/strong> object and that\u2019s true, I\u2019d personally write an integration<\/i> test for it to make sure that the database I\u2019m using is okay, that it understands my SQL and that the two entities (DAO and database) can talk to each other, but I won\u2019t bother unit<\/i> testing it.<\/p>\n
To conclude, unit tests must be meaningful, and a good a definition of \u2018meaningful\u2019 is that object under test must contain some independent logic.<\/p>\n
Reference: <\/i><\/strong>What Should you Unit Test? – Testing Techniques 3<\/a> from our JCG partner<\/a> Roger Hughes <\/span><\/span>at the Captain Debug blog<\/a><\/p>\n
Related Articles :<\/i><\/strong><\/p>\n