Great post. I've seen the cycle of misery a thousand times:
The code is "to simple to test."
The code grows. Each change is "too simple to test."
The changes start to interact, and produce strange edge cases. Some of these edge cases are intentional, some are accidental. Other code is built that depends on the current, undocumented behavior. The actual requirements are lost to time. The code is now "not really testable."
The code has become 2000 lines of if-else chains, copy-and-pasted code, and side-effected booleans. It has half a billion possible states, and can't be understood by mere mortals, or refactored without risk to the business.
A new feature is needed. A bright, shiny new bit of code is created, because adding anything more to the old code is madness.
The code for the new feature is "too simple to test."
Tests support many development goals. Verifying that the code works correctly now is just one. It's arguably more important to have tests that verify that the code continues to work as it changes over time.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Great post. I've seen the cycle of misery a thousand times:
Tests support many development goals. Verifying that the code works correctly now is just one. It's arguably more important to have tests that verify that the code continues to work as it changes over time.
I love it! The "cycle of misery" is the perfect term to describe it.