Pregression Testing
In the TDD process, our experience of writing tests guides our design decisions. However, when we use third-party components — be it an external service, a subsystem like a DBMS or message broker, or a library that we link into our own processes — we cannot change its design. We may be able to influence it, by requesting features or fixes for example, but the changes will not be implemented as rapidly as we can change our own code.
We often do not fully understand how the third-party code behaves. Its documentation may be incomplete or incorrect. It may contain defects we must work around that even its developers do not know about. When we write abstractions using third-party code, therefore, we use tests to verify that our abstractions behave as we expect: that our understanding of the third-party code is correct. We run these tests regularly to ensure that we do not introduce incorrect assumptions about the third-party components as we change our code.
But changes to the third-party components may break our code without us doing anything, forcing unexpected work upon us and disrupting our predictable rate of delivery. It's best to be warned of breaking changes as early as possible, so that the work to absorb them can be scheduled into the development work.