Question

I’m not brand new to the concept of unit testing but at the same time I’ve not yet mastered them either.

The one question that has been going through my head recently as I’ve been writing unit tests while writing my code using the TDD methodology is: to what level should I be testing?

Sometimes I wonder if I’m being excessive in the use of unit testing.

At what point should a developer stop writing unit tests and get actual work done?

I might need to clarify that question before people assume I’m against using TDD…

What I’m struggling with is the granularity of my test….

• When my app has a config file do I test that values can be retrieved from the file? I lean towards yes….but….
• Do I then write a unit test for each possible config value that will be present? ie check that they exist…and can be parsed to the correct type…
• When my app writes errors to a log do I need to test that it is able to write to the log? Do I then need to write tests to verify that entries are actually made to the log?

I want to be able to use my unit tests to verify the behavior of my app…but I’m not quite sure where to stop. Is it possible to write tests that are too trivial?

Answer 1

[Update:] Found the concise answer to this question in TDD ByExample – Pg194.

The simple answer, supplied by Phlip is, ‘Write tests until fear is transformed into boredom.’

[/Update]

I think the problem prevalent in the current times is the lack of unit testing… not excessive testing. I think I see what you’re getting at.. I wouldn’t term it as excessive unit-testing but rather.. not being smart about where you focus your efforts.

So to answer your question.. some guidelines.

• If you follow TDD, you’ll never have code that is not covered by a unit test.. since you only write (minimal) code to pass a failing unit test and no more. Corollary: Every issue should fail a unit test which pinpoints the location of the defect. The same defect shouldn’t cause tens of UTs to break simultaneously
• Don’t test code that you didn’t write. A corollary is: you don’t test framework code (like reading values from an app.config file) You just assume it works. And how many times have you had framework code breaking? Next to zero.
• If in doubt, consider the probability of failure and weigh that against the cost of writing an automated test case. Writing test cases for accessors/repetitive data-set testing included.
• Address the pain. if you find that you’re having issues in a certain area periodically, get it under a test harness.. instead of spending time writing redundant tests for areas that you know are pretty solid. e.g. A third party/team library keeps breaking at the interface.. doesn’t work like it is supposed to. Mocks won’t catch it. Have a regression type suite using the real collaborator and running some sanity tests to verify the link if you know its been a problem child.