Just realised, to get the worker config, you need the talk to the provider code, and the provider then needs to know the region, for which it needs to know what worker was created.

I might end up abandoning this... It might not be so easy to special case. For the fake worker pool definitions though, it would be sufficient to pull out the first workerConfig section from the first launchConfig, we don't need to do a region-lookup. So the test would create a fake worker pool definition like this one containing a single workerConfig in a single launch config, and registerWorker could return it.

But it only makes sense to implement this if it is a light touchpoint to the code e.g. inside a simple if statement to check the worker pool id, and pass back what it has before doing the more complex queries for other information about the worker that was created, that can be stubbed out with fake data. In the end the worker integration tests just care that they can get their config back, and the calls work to retrieve it.