Test Stubs as a Strategic Choice

A test stub is a simulator for an external system that you are not in charge of. A service you call and you need a reply from in order to process your business transaction. As an example an address validator in a e-commerce site, or as we have here locally an API to a government data repository.

A stub could just be an XML file of a few requests and replies that is polled instead of the external system. All addresses are valid besides a few who returns "non main land" delivery. While you can never simulate all business outcomes - you can get your testing flowing with a handful of outcomes. That you control.

But setting aside budget in a development project to build a stub is often disregarded or postponed. The testers have to work their way around it. Some might happily be enjoying a live connection to a test instance of the external system and forget all about eventually building a stub.

If you are in a place that always builds a stub, appreciate it. It still happens in 2025 that systems are designed with a too big dependency on externally controlled systems. This is a called to action to control your testing flow yourself.

A Situation

The system landscape in my current project has 30 external integration points, all of them are active on Prod. We have 4 non-prod environments, each with their unique mix of active integrations. The availability of environments on the other side is out of our hand, as some of the external connections have never had a test environment. Another point, we can have it if we pay €1 Mill pr year for the option.

For years this setup can continue as long as all things stay the same. The same delivery team, the same integrations etc. Continue happily with the known available integrations in the test environment and none in dev.

The Challenge

For strategic reasons the complete system portfolio - all environments - needs to be moved to a new delivery team and new/upgraded technology stack. In the above example the current delivery team team was just the first custodian of the solution on behalf of the customer. When the renewal of the outsourcing contract came up, someone else won, and the whole thing needed to be migrated/transitioned. And tested in the new location - that's where I come in. Hi. I'm the person in charge of testing the new setup. I handle challenges like this.

Complication

Let's call the system at the new vendor N - and previous vendor S. The complication is that while we build N-test and N-prod we need active integrations to the other parties: E1, E2, E3. With stubs it would be trivial to have our own "local" environment.

At the dedicated day of cut over Prod needs to move to N-Prod and the prod integrations too. It's on of the bigger impediments, as the integration parties might now be able to switch integration point in the way we intent. Perhaps they only have an end of month service window, we we need a mid month window. Perhaps we need to exchange certificates and update whitelists.

Another hurdle is on the test environment. The customer (system owner) usually expects that we can run a full business test on N-test with ALL integrations. Then we need to discuss the impact and cost of not having E2. We need to discuss with the current dev team to share their E1 and E3. Or ask E1/E3 for a separate instance. Leading to all kind of scheduling and pricing discussions - plus the simple fact of one system having to communicate the same to two master systems.

The Strategic Solution

I have seen the above happening at least twice - it's a mess, a cause for burnout and legal disputes. The customer wants to see that the new vendor (N) can test everything in N-test, but the vendor cannot, as they have no reach over E1, E2 - as those integrations are tied to the S instance.

The strategic solution is to build all the stubs.

I am sure that an analysis will find that the one-off investment of building the three stubs - and maintaining them moving forward will have a great payoff in less fear, uncertainty and doubt.

It is an investment into making their system self reliant and thus easier to develop and easier to test in. In can help to increase time to market, and better confidence in the test results too. As the test would be more repeatable. And it can make wrinkles disappear too. This would strategically allow for system complex to be more easy to transition and scale with more environments.

While it seems test stubs have a insignificant importance and are for testers only. There is a strategic impact not having them. The bigger picture gets lost when we are bickering over which road to take through the landscape.