Unit Tests as a Limitation

I believe it was Uncle Bob that in a beautiful take on explaining the paradigms of Procedural, ObjectOriented and Functional Programming explained that these paradigms are defined not by things they add but by the things they forbid. Without any paradigm you are free to solve your software problems by filling your code with GOTO statements. It’s the paradigms you chose to follow that add the desirable limitations that prevent you.

This is how we create order where chaos is expected. We impose well measured constraints that let our code, if we’re lucky, converge towards order. Javascript is not popular because of its huge vocabulary of features but rather because its limiting single threaded approach prevents you from making things. Go consciously decided to keep the language small. Simplicity is beauty.

This principle strikes me as I’m refactoring some old untested code. You see unit tests are also a limitation. They force you to structure your code in specific ways. They hinder you from using static variables and putting all your logic in big balls of mud. As you come in afterwards and try to create tests after the code was created you might notice that the code that previously was written without these limitations might not be as willing as you had hoped to shape itself according to your will. If you are prototyping something and think that tests are best left on the side for now to be quick, please be conscious that if you want to refactor your code later to make it more proper, you might be up for a rude awakening.