Page History

...

Github site: https://github.com/nasa/earthdata-search

Git Stash Bitbucket site: https://git.earthdata.nasa.gov/projects/EDSC

...

...

Tests should describe how the system responds to certain inputs. They should not simply duplicate the code under test.

Avoid over-mocking.

Ruby makes it very easy to stub methods and specify return values. Often, this can lead to fragile tests which don't perform any useful validation. If a test stubs every call made by a method, for instance, the test doesn't verify that the method actually works; simultaneously, the test will break any time the method changes.

Mocks couple tests and code, and should be used very sparingly. Valid reasons to use mocks include:

1. Calls to external services which cannot or should not be made during tests.
2. Calls which are expensive to perform (I/O) and irrelevant to the test at hand.
3. Calls which would require an unreasonable amount of setup and fixtures and are irrelevant to the test at hand.

When in doubt, it's better to not mock.

Minimize test suite execution time.

The test suite should provide developers with rapid feedback regarding the correctness of their code. To accomplish this, they should execute quickly. Keep performance in mind when writing tests. The following guidelines will help minimize execution time:

1. Test varying inputs and edge cases at the unit or functional level, rather than the integration level.
2. Avoid running integration tests with Javascript enabled unless Javascript is necessary for the feature under test.
3. Avoid calling external services, particularly ones which cannot be run in a local environment. Use mocks for these services.
4. Avoid loading external images, CSS, and Javascript in integration tests.
5. Avoid or disable interactions and interface elements that will cause Capybara to wait. For instance, disable animations or transitions.
6. Skip to the page under test in integration tests, there is no need to start at the home page for every test (though you should have a test which verifies you can start at the home page).
7. Avoid increasing timeouts to fix intermittent problems. Find other means.
8. Time your tests.
9. Follow this style guide for performant HTML, CSS, and Javascript.

If performance becomes a problem, we may segregate tests into "fast" and "full" runs, but ideally we will avoid this.

Fix sources of intermittent failures immediately.

If you see a failure and you suspect it was caused by some intermittent problem, e.g. a timeout that is too short or an external service being down, it is not enough to simply re-run the tests. Fix the problem. If a problem truly cannot be fixed, document why, catch the specific error that cannot be fixed, and throw a more meaningful one.

...

Minimize test suite execution time.

The test suite should provide developers with rapid feedback regarding the correctness of their code. To accomplish this, they should execute quickly. Keep performance in mind when writing tests. The following guidelines will help minimize execution time:

1. Test varying inputs and edge cases at the unit or functional level, rather than the integration level.
2. Avoid running integration tests with Javascript enabled unless Javascript is necessary for the feature under test.
3. Avoid calling external services, particularly ones which cannot be run in a local environment. Use mocks for these services.
4. Avoid loading external images, CSS, and Javascript in integration tests.
5. Avoid or disable interactions and interface elements that will cause Capybara to wait. For instance, disable animations or transitions.
6. Skip to the page under test in integration tests, there is no need to start at the home page for every test (though you should have a test which verifies you can start at the home page).
7. Avoid increasing timeouts to fix intermittent problems. Find other means.
8. Time your tests.
9. Follow this style guide for performant HTML, CSS, and Javascript.

If performance becomes a problem, we may segregate tests into "fast" and "full" runs, but ideally we will avoid this.

Fix sources of intermittent failures immediately.

If you see a failure and you suspect it was caused by some intermittent problem, e.g. a timeout that is too short or an external service being down, it is not enough to simply re-run the tests. Fix the problem. If a problem truly cannot be fixed, document why, catch the specific error that cannot be fixed, and throw a more meaningful one.

React testing library best practices:

• Avoid using test-ids where possible, this reduces our applications accessibility so use this sparingly
• Favor retrieving elements by Role  such as buttons, checkboxes etc. If there are multiple elements of the same role on a component use a secondary filter to ensure you select the correct ones for your assertions example: getByRole('button, {name: 'button-name'}
• Don't use await  statements for userEvent methods, userEvent is already wrapped in an await
• Using a container instead of screen to select elements on the virtual DOM
• Don't perform side effects within a waitFor  block
• For more see(https://kentcdodds.com/blog/common-mistakes-with-react-testing-library)

HTML

Use semantically meaningful elements where possible.

...

Minimize the overall depth of HTML to decrease page size, increase readability, and improve rendering speed.

Avoid conditional logic in views for partial display

Use view helpers for arbitrary display of content

See This example and description from Stack Overflow. Use Rails helpers to dynamically generate highlight dynamic HTML with widely varying elements and structure. Use Rails partials to generate more static content.

CSS with Sass

Earthdata Search uses SCSS to generate its CSS. It follows the guidelines for scalable CSS outlined by SMACSS, with key items reproduced in this document. The CI build checks CSS style using CSS Lint. Developers are strongly encouraged to read the CSS Lint rules.

...