From 48cc5749b07f44e9fc96ba2c3e3e90cf367b18ee Mon Sep 17 00:00:00 2001 From: Maikel Date: Wed, 1 Feb 2023 13:28:23 +1100 Subject: [PATCH] Invert convention on using I18n in specs --- Code-Conventions.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Code-Conventions.md b/Code-Conventions.md index cc30311..ae24edb 100644 --- a/Code-Conventions.md +++ b/Code-Conventions.md @@ -42,14 +42,21 @@ For positioning use % values, not viewport-units (vh, etc) (viewport-units are n ### Prefer `to have_not` as a feature matcher style (instead of `to_not have`) Reference: Capybara finders section of [this blog post](https://blog.codeship.com/faster-rails-tests/) for more details. -### Always use I18n.t in spec assertions -In specs, when asserting text that is translatable, always assert with a call to I18n.t, never use the translated string in english. +### Prefer plain text over method calls in expected values -Bad -`expect(json_response['errors']).to eq "Hm, something went wrong. No order cycle data found."` +For example, when asserting text that is translatable, use plain text instead of the `I18n.t` call. -Good -`expect(json_response['errors']).to eq I18n.t('admin.order_cycles.bulk_update.no_data')` +Bad: +``` +expect(json_response['errors']).to eq I18n.t('admin.order_cycles.bulk_update.no_data')` +``` + +Good: +```rb +expect(json_response['errors']).to eq "Hm, something went wrong. No order cycle data found." +``` + +This format is much easier to read. It's also more likely to find typos and bugs this way. # Performance