Trivial Pursuit: Unit-Testing Getters and Setters
While I was in Vegas, Eric, Alex, and Brian posted some ideas on unit testing trivial code.
The question: should we unit-test everything? The hive-mind currently says: yes.
E.g. Relevance recently posted a job offer that mentions 100% code coverage. At a recent NFJS, Stuart Halloway made the point that code coverage is one of the few things where one has to be extreme: 80% doesn't work; it has to be 100%. (Relevance is adamant on this point.)
Fine, so the answer is yes. But how do we remove the tedium of writing that testing code?
- Modern IDEs generate code for getters/setters. They should do the same thing for generating unit-tests for this code. I haven't seen this: perhaps they already do? I've looked in Idea 6 and didn't see anything obvious.
- It seems possible to write an abstract base class for unit-tests that uses reflection to auto-test common getters/setters. Is there such a tool out there?
- Interestingly, we are seeing the impact of this issue in language development. Groovy will auto-generate getters and setters for a class member if they aren't provided. Not only is there less code to read, but also there is less code to test.
ps. Here is a post from last winter on my experiences with unit-testing: in particular, TDD. It was a true growth experience for me.
pps. Here is the obligatory acknowledgement that getters/setters should not be automatically provided without just cause!
