Search This Blog


Monday, January 21, 2008

Excuses for Not Doing Unit Test

Although unit testing is now mainstream, but one can still avoid it if one is determined enough. Here are some of the excuses for not doing it that I have encountered over my professional life. Some are pretty easy to rebutted, some require a bit of thoughts to dispel, and some even genuine concerns.

See how many you can identify or rebutted!
  1. We can use Debug.Assert to capture problem during runtime, and this is something unit test cannot capture. Unit Test is not powerful enough, so don't use.
  2. Unit Test cannot capture all of the problems. For example, how you use unit test to test whether the pixel colors are rendered correctly on the screen? You can't right?
  3. Very difficult to write test cases, too time consuming!
  4. The test cases take a lot time to run! If we were to follow the whole TDD practice it would take us ages to finish our development.
  5. Unit Test deals with a well-defined input/output, but our ins and outs are poorly defined. We are developing the next generation natural language search algorithm and there is no such thing as an "expected output", you can only say this output is better than next output. How to unit test?
  6. Our inputs and outputs are too numerous, but unit test only works on small number of ins and outs. In order to setup a test case, we need to load tons and tons of information from database/text files and do some processing before getting to the logic class. Mocking those inputs are just plain not feasible. And checking the outputs are also not possible.
  7. Unit test works best on individual components, but not the interaction of components
  8. My code is jumbled up and it is impossible to separate into different components for proper unit testing
  9. Your unit test thing is just the system test in disguised , since we are not testers and system testing properly belongs to the testers, so we don't need to do it
  10. We have testers, so let them do all the testing, testing is none of our developer's business
  11. Most of our problems cannot be captured by unit tests, it can only be captured in system testing or functional testing
  12. We should have done this long time ago, but since we miss the bandwagon last time, so we can't do it now because we are already late into the development so it will take too much of our precious time. Sorry.
  13. In a nutshell, unit test is not doable. You just don't understand my situation here, I can't explain it to you.
Any more?


Sparky said...

Unit testing reminds me of my father.

"I don't have time to sweep the walk after I shovel it."

"Do you have time to do it over?"

Orion Letizi said...

Unit testing makes it hard (adds inertia) to refactor(ing) because you have to change all of the tests.

Anonymous said...

OMG! You didn't just say that! Unit testing ensures that the code returns the same expected results before and after refactoring. Unit testing makes it easy (ensures the code behaves the same as expected) to refactor because you can run tests that should have driven the design and eliminate the possibly quickly and easily that no new side effects were intrdouced during the refactor.

Anonymous said...

Yes, you may call me captain redundant... because I same the same thing twice. You know, like over and over again.

David Peterson said...

Unit testing works well for intra-unit refactoring, but not so well for inter-unit refactoring.

If you want to move parts of the logic from one unit to another, it will be a delicate and risky operation with unit tests alone.

Personally, I think unit tests are overrated and acceptance tests are underrated.


Soon Hui said...

I found another reason ( or excuse) not to do unit tests:

Unit tests are redundant

Sudeep D'Souza said...

Having tried to put a process in an organization for developing quality products I have heard a lot of excuses about how unit tests cannot be done and a lot of those excuses are covered in this article. The question is should unit tests be automated always - my answer is no. Unit test is making sure that the unit that is being developed is working according to the specification. So to try and make unit tests more formal I tried to leverage existing processes to improve the quality of unit tests and I have spoken about this process in my blog

Soon Hui said...


thank you for your comment.

But you said that one shouldn't automate unit test all the time. This seems puzzling. If unit test is not automated, then its benefits are lost, isn't it?