While this is potentially very dangerous because assigning the ID does
not increase the ID sequence, it's safe to do so in tests where we
assign the ID to every record created on a certain table.
Even so, I'd consider it a bad practice which must be used with care. In
this case I'm using it because we look for IDs in the response, and
most tests in this file use literals to compare the response.
This changes makes it possible to remove unused variables while keeping
the test readable.
Since we're obtaining titles and usernames in the response, it's easier
to compare them to titles and usernames we manually set.
Furthermore, this way we avoid many useless assignments.
While there are other variables in these tests, they're not part of the
setup of the test, and so these ones can be removed while keeping the
code easy to read.
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.
Proposal, Debate and Comment "globalize_accessors" class method were
loaded before application available locales initialization because of
graphql initializer. This will cause unexpected translation errors at
any translatable classes declared at graphql api definition (api.yml).
Doing GraphQL initialization after application initialization should
solve this issue.
