Listen to this post
The Open-Closed Principle (Bertrand Myers, Ivar Jacobsen) states, “Software entities (such as classes, modules, and functions) should be open for extension, but closed for modification.”
This means that a “good” design will allow for a new behavior to be added to a system without having to change the existing code, or at least to minimize those changes.
Of course, one cannot perfectly achieve such a thing, but trying to get as close as possible leads to systems that are far more resilient and extensible in the face of new business challenges/opportunities.
TDD relates to this in the following way.
When enhancing an existing system in TDD, we always start by writing a new (failing) test. The idea is then to do the work needed to make that test pass.
The question is, in doing this, did we break the older tests? If so, then we have discovered a lack of “open-closed-ness,” and we should investigate. If not, then we can confirm that our system does indeed follow this principle, at least in the area of concern.
No one can follow their principles perfectly, but when we do not follow them, we need to know about it, because it is an identified risk.