J’ai testé cela localement. Il semble y avoir plusieurs facteurs en jeu :
L’objet siteSettings auquel vous faites référence est obtenu par l’initialiseur, puis utilisé dans un appel modifyClass :
Les initialiseurs sont réexécutés pour chaque test. Le problème est que nous n’avons aucun moyen de « réinitialiser » les appels modifyClass qui ont été effectués par les tests précédents. Notre solution est le paramètre pluginId : cela signifie que seul le premier appel modifyClass de toute la suite de tests est réellement utilisé. Les appels à modifyClass provenant d’initialiseurs dans les tests futurs sont ignorés.
Normalement, cela convient, car le code à l’intérieur d’une invocation modifyClass ne change pas beaucoup à chaque exécution de test. Cependant, dans ce cas, vous faites référence à la référence siteSettings du scope des initialiseurs.
En bref : dans les tests, cette implémentation signifie que modifyClass sera bloqué avec les paramètres du site de celui des tests qui a été le premier à s’exécuter.
La solution consiste à utiliser une référence siteSettings « au moment de l’exécution » plutôt qu’au « moment de l’initialisation ». Nous pouvons utiliser celle de model:composer lui-même. Ce diff permet aux tests de passer pour moi :
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 &&