Strano comportamento di QUnit?: il test fallisce perché impostare il valore non sopravvive

Sviluppatore
1

Ho un problema strano con QUnit.

Questo test è estremamente semplice e dovrebbe essere diretto… ma…

Un’impostazione del plugin sta cambiando rispetto a quelle che ho configurato.

Quando il javascript viene eseguito come risultato del caricamento del Composer, il valore dell’impostazione impostato in precedenza nel blocco di accettazione non è più lo stesso!

Dovrebbe essere “user” come impostato nel codice del test, ma se viene registrato nella console, questo è ciò che vedo, ed è il motivo per cui il test fallisce:

image
image828×133 2.65 KB

Sto facendo qualcosa di stupido qui? Perché il valore di location_topic_default cambia da user a none?

Si noti il valore predefinito:

L’ambito di needs.settings è presumibilmente corretto qui?

È quasi come se le needs.settings venissero eseguite fuori ordine e oltre l’ambito acceptance…

2 Mi Piace
2

Ho provato questo localmente. Sembra che ci siano alcuni fattori in gioco:

L’oggetto siteSettings a cui fai riferimento viene ottenuto dall’inizializzatore, e poi utilizzato in una chiamata modifyClass:

Gli inizializzatori vengono rieseguiti per ogni test. Il problema è che non abbiamo modo di “resettare” eventuali chiamate modifyClass che sono state effettuate dai test precedenti. La nostra soluzione è il parametro pluginId - significa che solo la prima chiamata modifyClass nell’intera suite di test viene effettivamente utilizzata. Le chiamate a modifyClass dagli inizializzatori nei test futuri vengono ignorate.

Normalmente va bene - il codice all’interno di un’invocazione modifyClass non tende a cambiare in ogni esecuzione del test. Tuttavia, in questo caso stai facendo riferimento al riferimento siteSettings dallo scope degli inizializzatori.

Il tl;dr qui è: nei test, questa implementazione significa che modifyClass rimarrà bloccato con le impostazioni del sito dall’ultimo test che è stato eseguito per primo.

La soluzione è utilizzare un riferimento siteSettings “al runtime” piuttosto che al momento dell’“inizializzatore”. Possiamo usare quello da model:composer stesso. Questa diff fa passare i test per me:

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 Mi Piace
3

David, grazie mille! È una bella insidia!

1 Mi Piace
4

David,

FYI

C’è un altro problema qui che sospetto sia dovuto allo stesso motivo:

currentUser è definito anche nell’inizializzatore.

Se il test sbagliato viene eseguito per secondo, questo viene valutato e non è più definito, quindi i test quando vengono eseguiti insieme possono fallire “metà” delle volte.

Penso che il modello Composer abbia user, quindi passerò a quello…

2 Mi Piace
5

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