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.
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.
After adding proposal 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.
Skipping a spec in the middle of it, particularly after doing some
requests, caused Capybara to keep using the same driver in the following
spec.
Since the current spec uses the JavaScript driver, the next test would
also use the JavaScript driver, causing apparently random failures if
that test was supposed to use the Rack driver.
The example tests if a certain selector is hidden after adding
one image but the assertion expected said selector to be visible,
which made the scenario to fail at random
