Seltsames QUnit-Verhalten?: Test schlägt fehl, da das Setzen des Wertes nicht überlebt

Entwickler
1

Ich habe ein seltsames Problem mit QUnit.

Dieser Test ist extrem einfach und sollte unkompliziert sein … aber …

Eine Plugin-Einstellung ändert sich von dem, was ich eingerichtet habe.

Wenn das JavaScript als Ergebnis des Ladens des Komponisten ausgeführt wird, ist der früher im Akzeptanzblock gesetzte Einstellungswert nicht mehr derselbe!

Er sollte “user” sein, wie im Testcode festgelegt, aber wenn er in der Konsole protokolliert wird, sehe ich Folgendes, und deshalb schlägt der Test fehl:

image
image828×133 2.65 KB

Mache ich hier etwas Dummes? Warum ändert sich der Wert von location_topic_default von user zu none?

Bitte beachten Sie den Standardwert:

Der Geltungsbereich von needs.settings ist hier vermutlich korrekt?

Es ist fast so, als ob die needs.settings außer der Reihe und außerhalb des acceptance-Geltungsbereichs ausgeführt werden …

2 „Gefällt mir“
2

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 &&
2 „Gefällt mir“
3

David, vielen Dank! Das ist eine echte Tücke!

1 „Gefällt mir“
4

David,

FYI

Es gibt hier ein weiteres Problem, das ich aus demselben Grund vermute:

currentUser ist auch im Initialisierer definiert.

Wenn der falsche Test als zweites ausgeführt wird, wird dieser ausgewertet und ist nicht mehr definiert, sodass die Tests, wenn sie zusammen ausgeführt werden, “die Hälfte” der Zeit fehlschlagen können.

Ich denke, das Composer-Modell hat user, also werde ich darauf umsteigen …

2 „Gefällt mir“
5

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