Relax coverage criteria

[benthorner]

This adds support for a couple of unusual ways of calling I18n that weren't previously counted as part of the coverage. Please see the commits for more details.

[vincent-psarga]

That's nice :) So if I understand the PR, it means that if we use lookup to get a translation instead of translate, it will also be counted as a user translation key ? What is the purpose/benefit behind using lookup instead of translate ?

[benthorner]

@vincent-psarga it's quite a subtle (and frankly optional) change!

Sometimes we have a view that uses a large group of translations, depending on a variable.

# views/my_view.html.erb
...
<%= t("my_view.large_group.#{variable_with_lots_of_values}") %>
...

We could test this view and cover all the translations using a repetitive view test.

# my_view_spec.rb
all_values_for_variable.each do |value|
  it "renders correctly for #{value}" do
    render partial: "my_view", locals: { variable_with_lots_of_values: value }
  end
end

But that's inefficient (due to all the rendering). This is faster e.g.

# variable_with_lots_of_values_spec.rb
all_values_for_variable.each do |value|
  it "has a translation for #{value}" do
    expect(I18n.t("my_view.large_group.#{value}")).to be
  end
end

This is all good. But it would be a little clearer to write it like this:

# variable_with_lots_of_values_spec.rb
all_values_for_variable.each do |value|
  it "has a translation for #{value}" do
    expect(I18n.exists?("my_view.large_group.#{value}")).to be_truthy
  end
end

But this won't be counted as coverage, since it doesn't use translate.

[benthorner]

The other advantage of this change is that it also allows for other uses of translate that the current code doesn't pick up, such as I18n.t :record_invalid, scope: [:activerecord, :errors, :messages] (from the Rails I18n guide).

[benthorner]

Woah, what happened to the font?!