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.
We already configure `I18n.locale` and we reset Globalize's fallbacks
before every test.
On the other hand, RSpec automatically resets anything which is stub
with `allow`, so there's no need to use `and_call_original` in an
`after` block.
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.
GitHub treats help-wanted as a special label, so we're using it instead
of PRs welcome.
I'm still keeping the "PRs welcome" text and icon because it sound less
aggressive than "help wanted".
While the test should work without this assertion, the intention of the
test is to check what happens if a user selects and investment and, once
it's selected, clicks the "next" link.
When we were inserting a row or replacing an existing one (just like we
do when we click the link to select an investment), we were entering a
row containing all columns, and all of them were displayed even if they
had been excluded using the column selector.
This caused the table to move in a strange way, which sometimes made the
investment selection tests fail.
This way we can reduce the number of locales used in the test
environment as well, while still testing every possible scenario for
remote translations.
Using `Array(0, 1, 2)` will *not* create an Array with the elements
[0, 1, 2]. This is a mistake I've seen in the past, and the JavaScript
community recommends adding this rule.
It's very easy for Ruby developers to omit the `return` statement in an
array callback, such as the ones in `map` or `filter`. Doing so will
make those funcions have the same effect as `forEach`, which is usually
not the intended behaviour.
