We use staging and preproduction environments, which are not valid by
default.
This rule is useful because misspelling the name of an environment might
otherwise go unnoticed.
The Rakefile and config.ru files are now included by default, and the
behaviour of `Include` changed in Rubocop 0.56.0 (see rubocop's pull
request 5882) so now it **only** includes the files defined there, while
in the past it included those files in addition to the default files.
There was a rare case we've found on some Travis builds where the system
time suddenly moved back to the past a couple of tenths of a second,
meaning `Time.current - resource.created_at` returned a negative number,
which lead to a division by zero.
We're reading the value from the database, but the
`ApplicationMailer.default` method is evaluated when the application is
started. So if we don't use a Proc, we'll need to restart the server
every time we change the value in the database, or else the old value
will still be used.
Using a Proc makes sure the mailer from address is evaluated at runtime,
so emails are sent using the from address currently defined in the
database.
The same situation took place using the devise mailer. Now we don't need
to check for the settings table being present because the Proc in the
devise initializer won't be evaluated before the settings table is
created and populated.
We were performing an AJAX request and then a "normal" request without
checking the AJAX request had finished. Sometimes it resulted in the
normal request finishing because the AJAX request did, causing the test
to fail.
We're getting a failure on Travis in one of these tests. Debugging shows
the AJAX request rendering the first page (after clicking the "Previous"
link) takes too long and sometimes it exceeds Capybara's timeout.
After running the test thousands of times, the only way I've found to
clearly reduce the number of times the test fails is to reduce the
number of records shown on the first page. Other experiments, like
adding an `includes(:author)` to the query getting the proposals in the
controller, or adding `author: user` to the `create_list` part of the
test (so only one author needs to be fetched when rendering the
proposals) show inconsistent results regarding performance.
Note we still need at least 10 proposals for the test for several users,
to guarantee two users will never get the same records during the test
(or at least the probability they get the same records is one in
millions).
The tests in the `spec/lib/graphql_spec.rb` failed sometimes because
creating a record with a tag list of ["health"] when both "health" and
"Health" tags exist might assign either one of them. These tests usually
pass because we create two records and just by chance usually one of the
records gets one tag and the other one gets the other tag. However, the
test was written as if we expected the first record to get the first tag
and the second record to get the second tag, while very often the tests
were passing because the first record got the second tag and the second
record got the first tag. And when both records get the same tag, the
tests fail.
So I've changed these tests to tags are assigned directly and, since we
want to test the `tag_list` method, I've also added some tests to the
Tag model, which reflect the current behaviour: a random tag is assigned
when several tags with the same case-insensitive name exist.
Another option to assign the right tag to the record we're creating
would be to add `ActsAsTaggableOn.strict_case_match = true` to an
initializer. However, that would also create new tags on the database
when we accidentally assign a tag like "hEaLth" (like in the test we add
in this commit). Ideally we would have a strict case match for existing
tags and a non-strict case match for new tags, but I haven't found a way
to do it.
We don't need to create a heading every time we create an investment; we
can use an existing one by default.
Some tests are now much faster and don't fail on Travis due to reaching
Capybara's timeout anymore.
The images from OpenStreetMap take a while to load, sometimes even
causing Net::ReadTimeout errors if the internet connection is slow. It's
happened a lot recently on Travis builds.
Using capybara-webmock we guarantee the test suite doesn't fail due to
network issues.
