This enables code coverage analysis when running specs in your dev
environment. Simply run them as usual and you'll see a line like the
following at the end of the output:
Coverage report generated for RSpec to /home/pau/dev/openfoodnetwork/coverage
Simply browse to coverage/index.html and the results in a web UI.
This is a useful tool that helps you decide if the tests you added are
enough or not.
This may lead to more error reports than we want to see. A not existing
email address may cause Bugsnag to be notified. If this happens, we can
rescue form these specific errors and only report the rest.
The most common failure would happen when sending the confirmation email
triggered by `user.save`. We rescue any errors here and give feedback to
the user.
This allows for immediate feedback when the user types an email address
that is not accepted by our mail server or the email setup is not
configured properly.
This conversion is done by Transpec 3.3.0 with the following command:
transpec spec/controllers/user_registrations_controller_spec.rb
* 10 conversions
from: obj.should
to: expect(obj).to
* 7 conversions
from: == expected
to: eq(expected)
For more details: https://github.com/yujinakayama/transpec#supported-conversions
Using deferred methods on the user model breaks delayed jobs when the
user is deleted while the job still exists. We could create a proper job
referencing a user id for sending these emails instead. But since the
user has to wait for the confirmation email anyway, we can send it
within the current request. This should be revised if performance
becomes an issue.
Sending the email directly also has the advantage that we can tell the
user if emailing failed. See the following commits.
This change impacts a bunch of specs as we now need a working email
setup to create unconfirmed users. This commit introduces a custom
matcher to unify testing for confirmation emails.
One of the biggest pros of linters like Rubocop is to get valuable feedback to
help write better code. The way we have Rubocop configured now we don't prevent
new code from adhere improved code quality and this is specially important when
touching code that already suffers from complexity.
Without all Rubocop's Metrics cops enabled there's no way to get this insights
and write better code. This enables them while regenerating the
`.rubocop_todo.yml` to hide the current violations.
So, next time we touch existing code that we think could be simpler, we should
go to `.rubocop_todo.yml` and remove any occurrences of the file in question.
This way we could Rubocop's feedback right in the editor. This is tremendously
helpful when refactoring. It shows you where to start.
