Its all because you did not write a Unit Test…
Recently we realized that our server logs were showing ‘null’ for all HTTP request parameters values.
SEVERE: Attempting to get user with null userName parameters=[version:null][sessionId:null][userAgent:null][requestedUrl:null][queryString:null] [action:null][session:null][userIPAddress:null][year:null][path:null][user:null] |
On digging around a bit, we found the following buggy code in our custom Map class, which was used to hold the request parameters:
@Override public String toString() { StringBuilder parameters = new StringBuilder(); for (Map.Entry<String, Object> entry : entrySet()) parameters.append("[") .append(entry.getKey()) .append(":") .append(get(entry.getValue())) .append("]"); return parameters.toString(); } |
When we found this, many team members’ reaction was:
If the author had written unit tests, this bug would have been caught immediately.
Others responded saying:
But we usually don’t write tests for toString(), Getters and Setters. We pragmatically choose when to invest in unit tests.
As all of this was taking place, I was wondering, why in the first place, the author even wrote this code? As you can see from the following snippet, Maps already know how to print themselves.
@Test public void mapKnowsHowToPrintItself() { Map hashMap = new HashMap(); hashMap.put("Key1", "Value1"); hashMap.put("Key2", "Value2"); System.out.println(hashMap); } |
Output: {Key2=Value2, Key1=Value1} |
Its easy to fall into the trap of first writing useless code and then defending it by writing more useless tests for it.
I’m a lazy developer and I always strive real hard to write as little code as possible. IMHO real power and simplicity comes from less code, not more.
