Tests a feature via its external interface.

• spec/feature

Feature tests are slow, and a large number of them can have a significant effect on how long it takes to run the test suite. Consider whether or not your test can be written as a controller test or a unit test.

Tests that do not interact with user-facing features should not be written as feature tests.

If we're testing that errors are being sent to the frontend and displayed, we only need one feature test with a failure scenario. If there are multiple failing scenarios, those should be unit tests on the class that performs the validations.

Similarly, if we're testing a dropdown that gets populated with different values in different scenarios, we only need one feature test to make sure the dropdown appears. The logic for the other scenarios should be tested at the unit level.

Flakey Test Remedies

• Avoid using sleep in tests

• Avoid using a Capybara waiting finder with a negative matcher like:

  expect(page).not_to have_content("Missing Documents")

  The above code will try to find "Missing Documents" for the full timeout duration.

  Instead use a Capybara finder that will return immediately like:

  expect(page.has_no_content?("Activity for")).to eq(true)

Pattern	Description