Comportamento estranho no QUnit?: teste falhando pois o valor definido não persiste

merefield · Agosto 7, 2023, 10:05am

Tenho um problema estranho com o QUnit.

Este teste é extremamente simples e deveria ser direto… mas…

Uma configuração de plugin está mudando das que configurei.

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"

Quando o Javascript é executado como resultado do carregamento do Composer, o valor da configuração definido anteriormente no bloco de aceitação não é mais o mesmo!

Deveria ser “user” como definido no código do teste, mas se registrado no console, é isso que vejo, e por que o teste falha:

Estou fazendo algo estúpido aqui? Por que o valor de location_topic_default está mudando de user para none?

Por favor, observe o padrão:

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

O escopo de needs.settings está presumivelmente correto aqui?

É quase como se os needs.settings estivessem sendo executados fora de ordem e além do escopo acceptance…

david · Agosto 7, 2023, 10:53am

Eu testei isso localmente. Parece que há alguns fatores em jogo:

O objeto siteSettings ao qual você está se referindo é obtido pelo inicializador e, em seguida, usado em uma chamada 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;

Os inicializadores são executados novamente para cada teste. O problema é que não temos como “reiniciar” quaisquer chamadas modifyClass que foram feitas por testes anteriores. Nossa solução é o parâmetro pluginId - isso significa que apenas a primeira chamada modifyClass em toda a suíte de testes é realmente usada. Chamadas para modifyClass de inicializadores em testes futuros são ignoradas.

Normalmente, isso é bom - o código dentro de uma invocação modifyClass não tende a mudar em cada execução de teste. No entanto, neste caso, você está referenciando a referência siteSettings do escopo dos inicializadores.

O tl;dr aqui é: em testes, essa implementação significa que o modifyClass ficará preso com as configurações do site daquele teste que foi o primeiro a ser executado.

A solução é usar uma referência siteSettings “em tempo de execução” em vez de “tempo de inicializador”. Podemos usar a do próprio model:composer. Esta diferença faz com que os testes passem para mim:

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 · Agosto 7, 2023, 10:55am

David, muito obrigado! Isso é uma armadilha e tanto!

merefield · Agosto 7, 2023, 11:18am

David,

FYI

Há outro problema aqui que suspeito ser pela mesma razão:

currentUser também é definido no inicializador.

Se o teste errado for executado em segundo lugar, isso é avaliado e não está mais definido, então os testes quando executados juntos podem falhar “metade” do tempo.

Acho que o modelo Composer tem user, então mudarei para ele…

system · Setembro 6, 2023, 11:19am

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

Tópico		Respostas	Visualizações
Is it possible to override the Site object with own fixture during Front End tests of a Plugin? Dev	3	373	28 de Dezembro de 2022
Qunit tests not deterministic in Plugin? Dev	1	366	20 de Julho de 2022
Loading our SiteSetting properties before plugin loads Dev	14	3520	8 de Julho de 2016
Site Settings keep changing Installation unsupported-install	4	609	9 de Março de 2024
"No setting named __ exists" when trying to run specs on poll plugin Support	9	901	27 de Setembro de 2022

Comportamento estranho no QUnit?: teste falhando pois o valor definido não persiste

Tópicos relacionados