Backend Pattern Test Feature

[Pattern] Test - Feature

Description

Tests a feature via its external interface.

Location

• spec/feature

Best Practices

Consider whether you need a feature test

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.

Don't write a separate feature spec for each scenario

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.

find vs find_all

Flakey Test Remedies

Patterns to avoid

• 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)

Resources

Examples in Caseflow

Additional Reading

Related Patterns

Pattern	Description