Using @testing-library/react in Laboratory for e2e testing

[piyalbasu]

Problem:
We're in dire need of e2e testing that we can run in CI as we ramp up Lab Modernization. We need a safety net to establish a baseline of functionality so as we make changes to the codebase, we can have confidence we're not breaking things as we make changes. Ideally, this solution should be implemented in JS, have a good/familiar API, and be able to spin up quickly.

How @testing-library/react Addresses Our Needs: (https://testing-library.com/docs/react-testing-library/intro/)

• It's natively supported by Jest and Create React App, a stack we're already using.
• Testing-library features an API very similar to Enzyme (a common lib for UI testing in React). The API should look familiar to most JS devs.
• It runs "headlessly", meaning it both generates the UI and runs your tests in Node. This makes running tests very quick and lightweight. Excellent for CI.
• Uses promises to wait for changes in the UI. This is a pattern most JS devs are accustomed to:

  fireEvent.click(screen.getByText(/Generate keypair/i));

  const publicKeyresult = await screen.getByTestId("publicKey");

  expect(publicKeyresult).toHaveTextContent(PUBLIC_KEY)

Alternatives That We Passed On and Why:
We passed on solutions like Cypress.io or Selenium that are a bit more robust. These 2 solutions will actually open a browser and run the website, clicking on buttons and observing changes, as a real user would. These services are very useful, but:

• These programs are memory hogs and make not only running locally a little unwieldy, but can be difficult to run in CI.
• Setting up e2e frameworks like this tend to take a bit of time to setup/install and need a lot of tuning.
• Tests can be a little flaky as you're reliant on the machine that they're running on, to an extent.
• Their API's take a little time to parse and get rolling. For example, Cypress relies on timers, which takes some getting used to,
• We simply don't something that robust at this point. The benefits don't outweigh the cost of setup/onboarding.

[shanzzam]

Agree that using a more advanced feature set such as Cypress or Selenium is most likely overkill at this point in time.
Something that can quickly be setup and used by all is a huge gain for this project. As is running in Github Actions.

As we move forward with coding, a "Best Practices" doc in this repo would be useful. Not sure if that would go here in the Discussions or in a README in the test folder, or something similar.