Testes de internacionalização de Rails (I18n)

Hoje mesmo me deparei com uma postagem da Thoughtbot sobre teste de internacionalização (I18n) em seus testes de integração / recursos. No entanto, não concordo muito com a forma como estão usando a internacionalização em seus testes. Proponho uma solução diferente, vamos comparar:

Solução 1 (Thoughtbot)

spec/features/visitor_signs_in_spec.rb:

feature 'user views dashboard' do
  scenario 'sees welcome message' do
    user = create(:user)
    visit dashboard_path(as: user)

    expect(page).to have_content welcome_message_for(user)
  end

  def welcome_message_for(user)
    t('dashboards.show.welcome', user: user)
  end
end

Eles extraem o texto explícito do teste e testam com base no que a tradução retorna. Você esperaria que isso fosse bom, mas e se a tradução no arquivo de locales mudar? O teste ainda passa, mas algo mudou definitivamente. Portanto, você não está realmente testando sua visão, apenas se a tradução na página mostrar a mesma coisa que a tradução de seu teste. A grande vantagem disso é que você é flexível com seus testes, mas a grande desvantagem é que o teste não testa explicitamente o conteúdo da página.

Como poderíamos fazer de forma diferente?

Solução 2

Mantenha seu teste da maneira que o Thoughtbot se propõe, mas teste suas traduções explicitamente.
spec/translations/en/dashboard_translations_spec.rb:

describe 'Dashboard translation' do
  describe 'translates' do
    it 'welcome message' do
      user = create(:user)
      expect(I18n.t('dashboards.show.welcome', user: user)).to eql("Welcome #{user.name}")
    end
  end
end

Esta solução testará explicitamente se as traduções no arquivo de locales foram traduzidas corretamente. Isso permitirá que você permaneça flexível ( profissional ) em seus testes de integração / recursos e ainda teste as traduções. No entanto, eu poderia entender que você tenha a sensação de que está fazendo um trabalho um pouco duplo ( con ). Mas acho que vale a pena compensar.

Nota lateral: você pode pensar sobre o que você faz e não o que testar explicitamente. Por exemplo, teste: cabeçalhos, títulos, navegação, ect. explicitamente, mas bastante mutação / mudança de texto como: marketing, atualizações, ect. não.

TL; DR: torne seus testes de integração / recursos flexíveis incluindo I18n em seu teste, mas ainda teste o texto explícito com testes de tradução.