More Reasons For Testing: Prevent The Morning-After Syndrome
Testing (Test Driven Design, Unit Testing, Mocking) is a part of developer popular culture – most developers understand that by writing the tests first we’re forced to focus on the important details as we build software, that by writing tests we prove that our software works as we build it, and that by running our test suite against our changes we gain assurance that our code still works, but did you know that testing is also a cure for the ‘morning-after syndrome’?
The ‘morning-after syndrome’ as described by Uncle Bob (Robert C. Martin):
Have you ever worked all day, gotten some stuff working, and then gone home, only to arrive the next morning to find that your stuff no longer works? Why doesn’t it work? Because somebody stayed later than you and changed something you depended on! I call this ‘the morning-after syndrome’. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#
Bob makes the point that by writing tests we make our code more stable and brittle to change, which prevents our coworkers from making casual breaking changes. Sure-sure, brittle tests are frustrating when refactoring, but at the same time these brittle tests accentuate the importance that the code under test should not be modified. Core components that your system depends on should be stable and brittle.
Many factors make a software component difficult to change: its size, complexity, clarity, and so on. But we are going to ignore all those factors and focus on something different. One sure way to make a software component difficult to change is to make lots of other software components [like tests] depend on it. A component with lots of incoming dependencies is very stable, because it requires a great deal of work to reconcile any changes with all the dependent components. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#