I have a strange issue with QUnit. This test is extremely simple and should be straightforward … but … A plugin setting is changing from those I have set up. test/javascripts/acceptance/composer-default-location-test.js b87a63b54 boundingbox: ["51.2867601", "51.6918741", "-0.5103751", "0.3340155"], type: "city", }, }, }); needs.site(cloneJSON(siteFixtures["site.json"])); needs.settings({ location_enabled: true, location_users_map: true, hide_user_profiles_from_public: false, location_topic_default: "user", default_composer_category: 11, }); test("composer includes default location", async function (assert) { await visit("/"); await click("#create-topic"); assert.equal( query(".composer-controls-location span.d-button-label").innerText, "London, Greater London, England, United Kingdom" When the javascript runs as a result of the Composer loading, the setting value set earlier in the acceptance block is no longer the same! It should be “user” as set in the test code, but if console logged, this is what I see, and why the test fails: [image] Am I doing something stupid here? Why is the value of location_topic_default changing from user to none? Please note the default: config/settings.yml b87a63b54 default: false client: true location_country_default: default: '' client: true enum: 'LocationCountryDefaultSiteSetting' location_country_default_apply_to_all_searches: type: bool default: false client: false location_topic_default: type: enum default: none client: true choices: - none - user The scope of needs.settings is presumably correct here? It’s almost as if the needs.settings are running out of order and beyond the acceptance scope …

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: assets/javascripts/discourse/initializers/location-edits.js.es6 59525d1d82 export default { name: "location-edits", initialize(container) { const currentUser = container.lookup("current-user:main"); const siteSettings = container.lookup("site-settings:main"); const site = container.lookup("site:main"); assets/javascripts/discourse/initializers/location-edits.js.es6 b87a63b547 const topicDefaultLocation = siteSettings.location_topic_default; 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: diff --git a/assets/javascripts/discourse/initializers/location-edits.js.es6 b/assets/javascripts/discourse/initializers/location-edits.js.es6 index 19e50c0..9d5f882 100644 --- a/assets/javascripts/discourse/initializers/location-edits.js.es6 +++ b/assets/javascripts/discourse/initializers/location-edits.js.es6 @@ -83,7 +83,7 @@ export default { @observes("draftKey") _setupDefaultLocation() { if (this.draftKey === "new_topic") { - const topicDefaultLocation = siteSettings.location_topic_default; + const topicDefaultLocation = this.siteSettings.location_topic_default; if ( topicDefaultLocation === "user" && currentUser.custom_fields.geo_location &&

David, FYI There’s another issue here which I suspect is for the same reason: currentUser is also defined in the initialiser. If the wrong test runs second this is evaluated and this is no longer defined so the tests when run together can fail “half” of the time. I think the Composer model has user so I’ll switch to that …

Strange QUnit behaviour?: test failing because setting value doesn't survive

Development

merefield (Robert) August 7, 2023, 10:55am 3

David, thanks so much! That’s quite a gotcha!

Topic		Replies	Views
Is it possible to override the Site object with own fixture during Front End tests of a Plugin? Development	2	425	December 28, 2022
Qunit tests not deterministic in Plugin? Development	1	397	July 20, 2022
Loading our SiteSetting properties before plugin loads Development	14	3746	July 8, 2016
Site Settings keep changing Self-hosting unsupported-install	2	726	March 15, 2020
"No setting named __ exists" when trying to run specs on poll plugin Product Support	9	1073	September 27, 2022

Strange QUnit behaviour?: test failing because setting value doesn't survive

Related topics