How to Test a Shared Foundation Before It Breaks Apps

A shared foundation needs a higher testing bar than any single product, because a bug in the foundation is a bug in every product at once. When you change one product and break it, you have one problem. When you change the foundation and break it, you potentially have twenty problems, and you may not find out until each product deploys. The foundation is the highest-leverage code you own, which makes it the highest-stakes code you own. Test it like it.

How do I test code that twenty products depend on?

Two layers. Test the foundation in isolation, hard, and test that real products still work against a new version of it before you ship that version.

The first layer is straightforward: the foundation gets its own thorough test suite, treated with more rigor than product tests because its blast radius is larger. Every shared function, every piece of the auth flow, every billing path gets tested directly. This is the baseline for treating the internal platform as a real product: real products have real test suites, and the foundation is a product.

The second layer is what people miss. Unit-testing the foundation in isolation is not enough, because the failures that hurt are integration failures: the foundation changes in a way that is internally consistent but breaks how a specific product uses it. To catch those, you need tests that exercise real products against the candidate foundation version before it ships.

Contract tests: the cheap way to protect consumers

You cannot run every product's full test suite against every foundation change. That is too slow and you own too many products. What you can do is keep a thin contract test per product: a small check that exercises the handful of foundation surfaces that product actually depends on.

A contract test for a product answers one question: does this product's use of the foundation still work? It hits auth, does a database write, takes a payment, and confirms a deploy succeeds. It does not test the product's own features. It tests the seam between the product and the foundation. That seam is where shared-foundation bugs live.

Run every product's contract test against a foundation change before you tag it. If all pass, the change is safe to release. If one fails, you know precisely which product and which surface, before anything reaches production. This is what makes versioning the foundation trustworthy: you can promise a new version is safe because you verified it against every consumer, not because you hoped.

Additive changes still need tests, they are not free

There is a temptation to skip testing on additive changes because "additive means nothing breaks." Additive means nothing should break. The test is how you confirm it. An additive change can still break things through shared state, a dependency bump, or an assumption you did not know a product relied on.

So every foundation change runs the contract suite, additive or not. The additive discipline lowers the risk; the tests confirm the discipline held. Skipping tests on "safe" changes is how you learn which of your assumptions were wrong, in production, across multiple products. That is one of the mistakes that undermine a shared foundation over time: trusting the category of a change instead of verifying it.

Make the safe path the fast path

Testing a foundation is only sustainable if it is fast and automatic. If running the contract suite across twenty products takes an hour and a manual command, you will skip it under pressure, and skipping it is when the twenty-product outage happens.

I keep the contract checks thin and wired into the foundation's own pipeline, so changing the shared layer automatically runs every product's seam test. My build platform helps me find which products touch a changed surface, so Bootspring narrows the check to the consumers that matter and gives me the results before I tag a release. And because I run my own deploy pipeline, I can stage a new foundation version, run the suite, and promote it only when it is green, all without touching a cloud console.

The payoff is confidence. A well-tested foundation is one you can change often and calmly, because you know within minutes whether a change is safe for all twenty products. That confidence is what keeps a foundation compounding instead of freezing into the code everyone is afraid to touch.