A common practice taught in many TDD classes is the principle of too easy to test. The principle basically says that you should not test really simple things since then you will spend time writing tests that not really add value.

 

This is a fair recommendation and actually makes a lot of sense. Especially if you're implementing TDD in a team where people are a little bit skeptical. But there are a few dangers with allowing the use of this rule.

• Exactly what is considered too easy to test may be different if you ask different developers. Those who are reluctant to embrace TDD tend to stretch this line quite far.
• If something that once was really simple and then didn't need a test later on is changed to something more complex there is a risk that the developer will not add a new test since there was no tests before.

Personally I think that if something is considered to be so simple it does not need a test, it must be really simple to test. And if it so simple to test why shouldn't you use it. The relative cost might be high but the absolute cost for adding a real simple test for some real simple functionality is worth it in my book since it removes the decision from the developer. "No new functionality unless you have failing tests" is much simpler to follow and remember than "no new functionality unless you have failing tests or you consider the functionality to be really simple". Also consider the code coverage issues.