I think unit test coverage of anything but public entry points is unmitigated fanaticism. Any bug detected in testing requires investigation and that means debugging or tracelogging so should the bug be in an internal function then you’ll find it that way.

Another point: if changes in one module cause new bugs in another then there is likely a problem in clean isolation of implementation. I’ve seen a loss of esteem for object oriented principles (no, functional programming is not new) and the separation of interface and implementation. This is moving backwards.

But then a lot in software seems to be moving backwards.

I think writing fake data sets to back unit tests turns testing into a project in its own right, and the Windows 7 task that introduced me to the idea of TDD would have had unit tests several times the size of the project itself. I never did them; three hours of pair programming and I quit the job. It was creepy af.

But if we’re testing our tests an then testing the test tests we’ve gone down a rabbit hole.

Written by

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store