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.
While the correct usage would require an `in_time_zone` call, the code
can be simplified and the relationship between the current date and the
last `proposal.created_at + index.days` is now a bit easier to notice.
We use the beginning of the month as the date of the first action
because we expect all 8 actions to be created on the same month.
Using Date.today and Time.now is a common mistake which might lead to
obscure bugs. Now we're making sure we'll receive a warning when a pull
request uses these methods.
The dates are saved on UTC times on the database. So, for example,
if living in West Australia, `Date.current.beginning_of_day` will be
stored as UTC's yesterday at 15:15:00, while `Date.current.end_of_day`
will be stored as UTC's today at 15:14:59.
When we use the `DATE` database function, PostgreSQL will select the
records with the same UTC date as the current UTC date. However, we need
the records with the same application date (as defined in
`config.time_zone`) as the current application date. The test passed
(for us) because we were using `beginning_of_day + 3.hours` to make sure
we were creating records when the date in Madrid was the same as the UTC
date.
Using a ruby interval for the time condition solves the problem.
The label text was always in English, and it wasn't associated with any
input field.
The `SecureRandom` part is a quick hack so we don't get duplicate IDs.
Using "your_answer_#{question.id}" might work as well, but right now I'm
not sure if the form is sometimes rendered twice for the same question.
The statement executed the method twice if the `present?` condition was
true. If the condition was false, it executed it once anyway.
It's probably a typo and originally we probably meant we wanted to
execute the method if the method existed.
We're moving the code for the phases translation class to the same place
in the code the other translation classes are: right after including the
Globalizable module.
Not wrapping the editor in a `.ckeditor` div made it change height when
the editor was loaded. That caused a weird effect for users, and also
made some tests fail sometimes since the position of the "Add new
document" link might change right when capybara is clicking it.
The line:
```
config.i18n.load_path += Dir[Rails.root.join("config", "locales", "**", "*.{rb,yml}")]
```
Was adding every locale under the `config/locales` folder, including the
ones inside `config/locales/custom/`. The files were loaded in the same
order as listed using `ls -f`.
So if the custom locales were loaded before the folder
`config/locales/#{I18n.locale}`, the default locales would override the
custom ones, and we want the custom locales to override the default
ones so CONSUL is easier to customize.
This number was not the important one; the important one is the one
given by the recounts.
Note we're also removing the votes by date, since they're also system
votes.
System count isn't a relevant number because the important one is the
number of votes counted by poll officers. We're still maintaining it for
a month in case poll officers would like to review the results.
The reason for this rule is similar to dynamic factories: we want
dynamic dates to be evaluted relative to the current time, and not
relative to the moment the application was loaded.
Factory bot has stopped supporting dynamic attributes, and we'll have to
change all factories before upgrading.
In order to apply the rubocop rule, we need to bump rubocop-rspec to its
latest version.
These rules are now defined under `Style/`. However, we don't really use
them, so they add noise to the rubocop configuration file without
solving any issues we actually have.
Sometimes during this test some comments are not created (so far we
don't know why), but since all comments had the same text, we didn't
notice when checking the text of the comment was on the page.
When clicking the button "Search", the link "newest" is already present,
so capybara might click the "newest" link before the "Search" request is
finished, leading to unexpected results.
Checking the page to make sure the "Search" request has finished before
clicking the "newest" link solves the problem.
