raggedstaff/openfoodnetwork
1
0
Fork 0
mirror of https://github.com/openfoodfoundation/openfoodnetwork synced 2026-01-24 20:36:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Invert convention on using I18n in specs

Maikel
2023-02-01 13:28:23 +11:00
parent 6994d8e1ec
commit 48cc5749b0
1 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
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