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

**URL:** https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165
**Category:** Development
**Created:** [August 7, 2023, 10:05am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165 "2023-08-07T10:05:22Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 7, 2023, 10:05am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165/1 "2023-08-07T10:05:22Z")

</div>

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.

> <https://github.com/merefield/discourse-locations/blob/b87a63b547f8d6ef5af44077aae21126ee29bb59/test/javascripts/acceptance/composer-default-location-test.js#L75>

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](https://global.discourse-cdn.com/meta/original/4X/9/7/b/97b34ee9640363b0d2996f968564e1b78b87c4fa.png)

Am I doing something stupid here? Why is the value of `location_topic_default` changing from `user` to `none`?

Please note the default:

> <https://github.com/merefield/discourse-locations/blob/b87a63b547f8d6ef5af44077aae21126ee29bb59/config/settings.yml#L149>

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 …

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [August 7, 2023, 10:53am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165/2 "2023-08-07T10:53:24Z")

</div>

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:

> <https://github.com/merefield/discourse-locations/blob/59525d1d82/assets/javascripts/discourse/initializers/location-edits.js.es6#L13-L18>

> <https://github.com/merefield/discourse-locations/blob/b87a63b547/assets/javascripts/discourse/initializers/location-edits.js.es6#L86-L86>

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
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 &&

```

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 7, 2023, 10:55am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165/3 "2023-08-07T10:55:17Z")

</div>

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

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 7, 2023, 11:18am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165/4 "2023-08-07T11:18:24Z")

</div>

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 …

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [September 6, 2023, 11:19am UTC](https://meta.discourse.org/t/strange-qunit-behaviour-test-failing-because-setting-value-doesnt-survive/274165/5 "2023-09-06T11:19:24Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.