The attribute made sense before we changed it in commit ba1a6b4c. Since
then, all milestones have the same date, so the attribute doesn't affect
the test at all.
The group is automatically assigned when we assign the heading. The
budget isn't needed either, except for a special case related to the
reason to be rejected.
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.
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.
Settings are stored in the database, and so any changes to the settings
done during the tests are automatically rolled back between one test and
the next one.
There were also a few places where we weren't using an `after` block but
changing the setting at the end of the test.
We accidentally removed the `count` option in commit 55fb14ac, which
made the translation return a hash.
The test is a bit hacky, which makes me think changing the user
interface would probably be a better solution.
After adding investment translatable fields to forms, they will be
generated with nested translations names and ids so we can no longer
use standard id locator.
Using input label text to fill in fields works with both types of forms.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
We were expecting the page not to have content which is actually there.
The test passed (most of the time) because before clicking the
"Milestones" link the content was not present, and we checked the page
content before the AJAX request generated by clicking the link had
finished.
We were sending a new request without checking the previous one had
finished, and if it hadn't finished, the test failed.
This test started to fail after upgrading to Rails 5, since we removed
the change done in commit eda47eff which set `config.allow_concurrency`
to `false` in the test environment.
While we could re-introduce that configuration option, which might have
side effects, an easier solution is to check an AJAX request has been
completed before sending a new request depending on the previous one
seems to be a more solid option.
Note this test failed with two possible errors: "undefined method
`heading' for nil:NilClass" and "stale element reference: element is not
attached to the page document". This change fixes the second error; it
might fix the first error as well, but since I couldn't reproduce it
locally, we'll only be sure when this test stops failing in travis
builds.
There was a typo: `new_order = eq(all(` instead of `new_order = all(`,
which was causing the tests to pass.
However, the final expectation should test that we keep the same order
in the same session, and we were accidentally testing the opposite.
We're also adding an extra check to verify there are investments on the
page, since in some cases we were accessing pages with no investments,
and so these tests were always passing.
This is the actual number of investments per page in the index action.
Also note one test was generating 100 extra records, which made the test
take more than 40 seconds (on my machine).
