merefield is experiencing a strange issue with QUnit tests failing due to a plugin setting value changing unexpectedly. The value of location_topic_default is changing from “user” to “none” during the test run.
david investigated the issue and found that the problem is due to the way initializers work in QUnit tests. The siteSettings object is being obtained by the initializer and used in a modifyClass call, but this call is only executed once in the whole test suite. As a result, subsequent tests are stuck with the site settings from the first test.
david suggested a solution to use a site settings reference at runtime rather than at initializer time, and provided a diff to fix the issue.
merefield thanked david for the explanation and solution, and noted that there is another related issue with the currentUser variable being defined in the initializer. merefield plans to switch to using the user property from the Composer model to avoid this issue.
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:
