Every time I find it difficult to think of a good test to start, I am always tempted to try backdoors like getters, setters to help get started. The backdoors are not limited to getters and setters alone. Here is a list of my observations which has been used only for writing unit tests in Java easier.
- Equals implementation
- Protected or package private access specifiers for variables and methods
- ToString implementation
- Special backdoor methods to alter the state of an object (The worst of all)
Any line of code which exists other than for another production code, it encourages a programmer in the future to exploit that backdoor for quick gains. As the tests are the specification to the production software, it is better to resist the tempation to use any of these. It also causes increase in code length and also an excuse for more people to follow the same path. The more time and effort I had spent trying to avoid backdoors, I have benefitted with more clarity in design. The benefits have prompted me to have routine static checks in the code base to keep them at check.
A question and a counter argument posed by a peer who belonged to another school of thought. If tests are considered to be first class consumers of production code, then is it right to have some backdoors help ease writing tests faster? Comments?