Remove page-level client unit testing and implement e2e (integration) tests using Cypress

[joshuagraber]

Part of #248

Rationale

• All of the components in design-system have unit tests run against them on every push. Thus, unit testing components and pages here is superfluous and has diminishing returns for the labor involved.
• Instead, we want to test the application's critical flows end-to-end
• We should continue testing components, utilities, and any other encapsulated, simply testable functions.
• This should be done after the rest of the client work for #248

Here are the tasks involved. We may want to break these up into an epic later, as it's quite a lot of work.

• [ ] Remove client unit tests (will happen as a part of the search-v2 work)
• [ ] Install and configure Cypress, along with mock server and mock service worker
• [ ] Add testing fixtures
• [ ] Add e2e test for login flow
• [ ] Add e2e test for change/reset password flows
• [ ] Add e2e test for search, search results, and data source details flows
• [ ] Add e2e test for user profile
• [ ] Add e2e test for new data source request

[maxachis]

All of the components in design-system have unit tests run against them on every push. Thus, unit testing components and pages here is superfluous and has diminishing returns for the labor involved.

@joshuagraber I'm a little confused by this phrasing -- the components have unit tests run against them, thus unit testing components is superfluous? Do you mean that there are two different systems unit testing the same components, or something else?

[joshuagraber]

@maxachis Yes, I'm saying that unit testing is best for small, tightly encapsulated modules or functions.

We are continuing to run tests on any data-sources-app-specific components defined here, as well as utility functions and any other building blocks.

However, when composing those components into views, unit testing makes very little sense, in my opinion, because:

1. the building blocks are already unit-tested, making unit tests on views relatively superfluous.

2. Views combine components with asynchronous fetching logic and a lot of other side-effects, making unit testing views cumbersome and prone to flakiness.

For this reason, I think it is far more effective to integration test views.

In API terms, this would be (somewhat) analogous to the common practice of unit testing middleware and handlers, while integration testing the functionality of API endpoints.

[maxachis]

In API terms, this would be (somewhat) analogous to the common practice of unit testing middleware and handlers, while integration testing the functionality of API endpoints.

This I understand! And your rationale makes sense! One would assume that the integration tests would capture the interactions between the various building blocks enough, and that one doesn't need to necessarily test all the interactions, particularly if they are prone to being repeatedly revised and remixed -- that's a lot of potential combinations to test for with limited testing benefit when you already have the integration tests encapsulating a lot of it.