Do you do unit tests for non production code?

Question

I am interested in the following scenario specifically. Suppose you have team that writes production code and a team that writes automatic tests. The team that writes automatic tests has a dedicated framework intended to write the automatic tests. Should the testing team write unit tests for their framework although the framework is not used in production?

Answer 1

I've been in that situation and what I did is use the test suite for the production code also as a test suite for the testing framework. Presumably, all the features of the framework were actually used, so if tests failed without a change in production code, then there must be a problem in the testing framework.

It worked OK-ish - running those tests took much longer than having a dedicated test-testsuite would have, and sometimes I wouldn't run all of them and have a problem turn up on the production build server. Diagnosing such problems took much longer than it would have with a test-testsuite.

All in all, I never felt comfortable with it and would really recommend having dedicated tests for the test framework as well. From the point of view of the test-writing team, the testing framework is production code. And if the testing framework ever gets used by anyone else, whose test suites you don't have access to...

Answer 2

Hell yes!

TDD gives you an edge in developing, it's not just to please the customer. It allows you to write testable, reusable and modular code. I would unit test everything that has to work, expecially if you expect to change it often (refactor to add new features).