Don’t Test the Framework

You are more likely to succeed by leveraging the work of others than by duplicating their efforts. While you may find it fun to write your own <fill in your own pet project>, chances are good that someone else with greater expertise or experience has already written it, and hundreds or thousands of people are using it. Or it may be available as part of the standard features or libraries of your language of choice.

Frameworks, libraries, plug-ins, code generators, and their kin increasingly let us work at a higher and higher level of abstraction. Whether built in, commercial, or open source, we incorporate them into our development ecosystem and trust them to work correctly.

Commercial software comes with support and maintenance as well as—despite the license disclaimers—some expectation of fitness for purpose. The same is usually true of our system libraries, often including the backing design and support of a standards body in their design and specification. Open-source software comes with user communities and often includes test suites as part of their build and installation.

Generally, you do not need to test third-party code. I have lost count of the number of times I have seen developers, myself included, quickly jump to the conclusion that the compiler or library had a bug because it could not have been our mistake, only to realize after a long side trip that we should look at our own code first. Sure, sometimes shortcomings in the availability or quality of documentation contribute. Once in awhile, the bug really is in the third-party code. However, most of the problems are ours.

Someone else has done the work to guarantee the quality of the software. Let’s not duplicate their efforts.