Comportement QUnit étrange ?: le test échoue car la définition de la valeur ne survit pas

Dev
1

J’ai un problème étrange avec QUnit.

Ce test est extrêmement simple et devrait être direct… mais…

Un paramètre de plugin change par rapport à ce que j’ai configuré.

Lorsque le JavaScript s’exécute suite au chargement du Compositeur, la valeur du paramètre définie plus tôt dans le bloc d’acceptation n’est plus la même !

Elle devrait être “user” comme défini dans le code de test, mais si je fais un console.log, voici ce que je vois, et pourquoi le test échoue :

image
image828×133 2.65 KB

Est-ce que je fais quelque chose de stupide ici ? Pourquoi la valeur de location_topic_default passe-t-elle de user à none ?

Veuillez noter la valeur par défaut :

La portée de needs.settings est vraisemblablement correcte ici ?

C’est presque comme si les needs.settings s’exécutaient dans le désordre et au-delà de la portée acceptance…

2 « J'aime »
2

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 &&
2 « J'aime »
3

David, merci beaucoup ! C’est une sacrée surprise !

1 « J'aime »
4

David,

Pour information,

Il y a un autre problème ici que je soupçonne être dû à la même raison :

currentUser est également défini dans l’initialiseur.

Si le mauvais test s’exécute en second, celui-ci est évalué et n’est plus défini, de sorte que les tests lorsqu’ils sont exécutés ensemble peuvent échouer “la moitié” du temps.

Je pense que le modèle Composer a user, donc je vais passer à celui-ci…

2 « J'aime »
5

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