Ich habe das lokal ausprobiert. Es scheint, dass mehrere Faktoren eine Rolle spielen:
Das siteSettings-Objekt, auf das Sie verweisen, wird vom Initialisierer abgerufen und dann in einem modifyClass-Aufruf verwendet:
Initialisierer werden für jeden Test neu ausgeführt. Das Problem ist, dass wir keine Möglichkeit haben, modifyClass-Aufrufe, die von früheren Tests gemacht wurden, zurückzusetzen. Unsere Lösung ist der pluginId-Parameter – er bedeutet, dass nur der erste modifyClass-Aufruf in der gesamten Testsuite tatsächlich verwendet wird. Aufrufe von modifyClass aus Initialisierern in zukünftigen Tests werden ignoriert.
Normalerweise ist das in Ordnung – Code innerhalb einer modifyClass-Aufrufung ändert sich in der Regel nicht bei jedem Testlauf. In diesem Fall verweisen Sie jedoch auf die siteSettings-Referenz aus dem Gültigkeitsbereich des Initialisierers.
Das tl;dr hier ist: In Tests bedeutet diese Implementierung, dass modifyClass mit den Site-Einstellungen aus dem Test, der als erster ausgeführt wurde, feststecken wird.
Die Lösung besteht darin, eine siteSettings-Referenz zur Laufzeit anstelle zur Initialisierungszeit zu verwenden. Wir können die aus model:composer selbst verwenden. Dieser Diff lässt die Tests für mich erfolgreich durchlaufen:
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 &&