We barely use this trait. In the votation type spec we're probably using
it wrong, and in the answer spec we assume one of the answers is going
to be "Yes".
The name `yes_no` is more expressive, since it makes it clear what the
answers are.
These specs were added before we disabled featured proposals by default.
After that, they were passing, but they were not testing the scenario
they were supposed to test.
Before we disabled featured proposals by default, there were many tests
creating them because they were needed in order to create non-featured
proposals.
But now these tests don't need to create featured proposals anymore.
We had a case where we created 5 extra records in pagination and checked
2 records were present, because the other 3 were automatically
considered featured proposals.
Explicitely creating featured proposals let us create 2 extra records
and check 2 records are present, which is far more intuitive.
The "name" attribute is automatically generated by the budget heading
factory. And the "price" attribute is out of context and not needed
since this test doesn't create investments.
One test was testing regular users can't access results, and another one
was testing neither regular users nor managers can. So the second test
can just test the admin scenario, and we're still covering everything.
The factory creating assignments automatically assigns a poll to it, so
we don't use the poll for anything else, there's no need to explicitely
create it.
This data is obsolete since commit 9d1ca3bf.
Note we should have probably moved the test to the model, since now the
`to_csv` method isn't tested anywhwere, and we should probably add a
test in the future. The code now uses the new DownloadSetting model,
though, making it hard to test.
These feature tests were taking too long, we can't run them for every
single model.
I'm taking the approach of using one different model for each test, but
in theory only using a few models covering every possible scenario
would be enough.
So now we test in depth at the model level, and can be a bit more
relaxed about integration tests for translations.
Note we're defining some extra factories to make sure all translatable
attributes with presence validation rules are mandatory. This way we can
simplify the way we obtain required fields, using `required_attribute?`.
Otherwise, fields having an `unless` condition in their presence
validation rules would count as mandatory even when they're not.
This is a mistake I made in commit f2ef27d3. Back then I thought we
needed to keep Globalize.locale and I18n.locale in sync, but the truth
is it automatically happens when setting Globalize.locale to nil.
So now we can use I18n.with_locale (at least in the tests) and forget
about Globalize, which will make it easier to switch to Mobility in the
future.
We don't need `before` blocks because we've removed the `after` blocks,
and we don't need to define available locales because we already do so
in the test environment file.
Now factories define default headings for investments, so there's no
need to create a group and a heading to create an investment.
Likewise, in order to create a heading it isn't necessary to specify a
group anymore; specifying the budget is enough.
It's possible that there are more similar cases we haven't simplified
yet; I'm only addressing the obvious ones.
These settings are enabled by default.
It could be argued explicitely enabling the features makes tests more
consistent, because they'll work if we change the default setting. It
could also be argued that it makes tests more expressive because it
makes the reader realize certain things will only work if a setting is
enabled.
However, we were only doing so in a few tests. The truth is, thousands
of our tests depend on certain features being enabled. So IMHO we should
be consistent and either set them on every test, or not at all. I'm
choosing the latter option for simplicity.
