¿Comportamiento extraño en QUnit?: la prueba falla porque el valor no perdura

merefield · 7 Agosto, 2023 10:05

Tengo un problema extraño con QUnit.

Esta prueba es extremadamente simple y debería ser sencilla… pero…

Una configuración de plugin está cambiando de la que he configurado.

github.com/merefield/discourse-locations

test/javascripts/acceptance/composer-default-location-test.js

b87a63b54


      
                boundingbox: ["51.2867601", "51.6918741", "-0.5103751", "0.3340155"],
                type: "city",
              },
            },
          });
          needs.site(cloneJSON(siteFixtures["site.json"]));
          needs.settings({
            location_enabled: true,
            location_users_map: true,
            hide_user_profiles_from_public: false,
            location_topic_default: "user",
            default_composer_category: 11,
          });
          
          test("composer includes default location", async function (assert) {
            await visit("/");
            await click("#create-topic");
          
            assert.equal(
              query(".composer-controls-location span.d-button-label").innerText,
              "London, Greater London, England, United Kingdom"

Cuando el javascript se ejecuta como resultado de la carga del Compositor, ¡el valor de configuración establecido anteriormente en el bloque de aceptación ya no es el mismo!

Debería ser “user” como se establece en el código de prueba, pero si se registra en la consola, esto es lo que veo, y por qué la prueba falla:

¿Estoy haciendo algo estúpido aquí? ¿Por qué el valor de location_topic_default cambia de user a none?

Por favor, tenga en cuenta el valor predeterminado:

github.com/merefield/discourse-locations

config/settings.yml

b87a63b54


      
            default: false
            client: true
          location_country_default:
            default: ''
            client: true
            enum: 'LocationCountryDefaultSiteSetting'
          location_country_default_apply_to_all_searches:
            type: bool
            default: false
            client: false
          location_topic_default:
            type: enum
            default: none
            client: true
            choices:
              - none
              - user

¿El alcance de needs.settings es presumiblemente correcto aquí?

Es casi como si las needs.settings se ejecutaran fuera de orden y más allá del alcance de acceptance…

david · 7 Agosto, 2023 10:53

Lo probé localmente. Parece que hay varios factores en juego:

El objeto siteSettings al que te refieres se obtiene mediante el inicializador y luego se utiliza en una llamada a modifyClass:

github.com/merefield/discourse-locations

assets/javascripts/discourse/initializers/location-edits.js.es6

59525d1d82


      
          export default {
            name: "location-edits",
            initialize(container) {
              const currentUser = container.lookup("current-user:main");
              const siteSettings = container.lookup("site-settings:main");
              const site = container.lookup("site:main");

github.com/merefield/discourse-locations

assets/javascripts/discourse/initializers/location-edits.js.es6

b87a63b547


      
          const topicDefaultLocation = siteSettings.location_topic_default;

Los inicializadores se vuelven a ejecutar para cada prueba. El problema es que no tenemos forma de “restablecer” ninguna llamada a modifyClass que se haya realizado en pruebas anteriores. Nuestra solución es el parámetro pluginId, lo que significa que solo se utiliza la primera llamada a modifyClass en toda la suite de pruebas. Las llamadas a modifyClass de inicializadores en pruebas futuras se ignoran.

Normalmente, eso está bien, ya que el código dentro de una invocación de modifyClass no tiende a cambiar en cada ejecución de prueba. Sin embargo, en este caso, estás haciendo referencia a la referencia siteSettings del ámbito del inicializador.

En resumen: en las pruebas, esta implementación significa que modifyClass se quedará con la configuración del sitio de la prueba que fue la primera en ejecutarse.

La solución es usar una referencia siteSettings “en tiempo de ejecución” en lugar de “en tiempo de inicializador”. Podemos usar la del propio model:composer. Esta diferencia hace que las pruebas pasen para mí:

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 &&

merefield · 7 Agosto, 2023 10:55

¡David, muchas gracias! ¡Eso es toda una trampa!

merefield · 7 Agosto, 2023 11:18

David,

Para tu información,

Hay otro problema aquí que sospecho que se debe a la misma razón:

currentUser también está definido en el inicializador.

Si la prueba incorrecta se ejecuta en segundo lugar, esta se evalúa y ya no se define, por lo que las pruebas cuando se ejecutan juntas pueden fallar “la mitad” del tiempo.

Creo que el modelo Composer tiene user, así que cambiaré a ese…

system · 6 Septiembre, 2023 11:19

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

Tema		Respuestas	Vistas
Is it possible to override the Site object with own fixture during Front End tests of a Plugin? Dev	3	373	28 Diciembre 2022
Qunit tests not deterministic in Plugin? Dev	1	366	20 Julio 2022
Loading our SiteSetting properties before plugin loads Dev	14	3520	8 Julio 2016
Site Settings keep changing Installation unsupported-install	4	609	9 Marzo 2024
"No setting named __ exists" when trying to run specs on poll plugin Support	9	901	27 Septiembre 2022

¿Comportamiento extraño en QUnit?: la prueba falla porque el valor no perdura

Temas relacionados