I took this for a spin locally. Looks like there a few factors at play:
The siteSettings object you’re referencing is being obtained by the initializer, and then used in a modifyClass call:
Initializers are re-run for each test. Problem is, we have no way to ‘reset’ any modifyClass calls that were made by previous tests. Our solution is the pluginId parameter - it means that only the first modifyClass call in the whole test suite is actually used. Calls to modifyClass from initializers in future tests are ignored.
Normally that’s fine - code inside a modifyClass invocation doesn’t tend to change in each test run. However, in this case you’re referencing the siteSettings reference from the initializers scope.
The tl;dr here is: in tests, this implementation means that the modifyClass will be stuck with the site settings from whichever test was the first to run.
The solution is to use a siteSettings reference ‘at runtime’ rather than at ‘initializer’ time. We can use the one from model:composer itself. This diff gets the tests passing for me: