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