New UI testing framework for the web

[LorenzoBloedow]

In order to properly evaluate if a new library can be added to package.json, please fill out this request form. It will be automatically assigned someone from our review team that will go through and vet the library.

In order to add any new production dependency, it must be approved by the App Deployer team. They will evaluate the library and decide if it's something we want to move forward with or if other alternatives should be explored.

Note: This is only for production dependencies. While we don't want people to add packages to dev-dependencies willy-nilly, we recognize that there isn't as great of a need there to secure them.
I think this is a somewhat big change, it's not just a random dev dependency, if approved, it'll change the testing workflow and maybe even the guidelines on when to write UI tests, that's why I've ignored the warning above.

Note: Text written before ", peer dependency" refers to @testing-library/dom. Since we don't plan on directly using it, I didn't think it was necessary to duplicate the template.

Name of library: @testing-library/react, (+ @testing-library/dom, peer dependency).

Details

• Link to package: https://github.com/testing-library/react-testing-library (https://github.com/testing-library/dom-testing-library, peer dependency)
• Problem solved by using this package: We don't have a way to test isolated UI components on the web, this leads to browser edge cases such as this only being caught by QA (Applause) on their E2E and manual tests.
  Adding support for the proposed libraries means we'd be able to iterate on PRs much faster as detecting web-specific regressions would be as easy as running the tests. As more UI tests for the web are written, It'll also probably make deploy blockers less frequent because regressions will be caught before even merging to main.
  Note: we do have "@testing-library/react-native", which is the version of the proposed library but for RN, but it's not the same thing.
• Number of stars in GH: 19.3k (3.3k, peer dependency).
• Number of monthly downloads: ~57.7M (~86.8M, peer dependency) (according to npmcharts.com).
• Number of releases in the last year: 18 (9, peer dependency) (counted all releases that NPM says were published at most a year ago).
• Level of activity in the repo: 50 open issues, 769 closed issues, 5 open PRs, 505 closed PRs (87 open issues, 522 closed issues, 29 open PRs, 681 closed PRs, peer dependency).
• Alternatives: https://github.com/enzymejs/enzyme and E2E testing frameworks such as Playwright (E2E testing is usually much slower).
• Are security concerns brought up and addressed in the library's repo? No (dev dependency, usually not a problem to the end user).
• How many dependencies does this lib use that will be brought into our code? 1 dep, 13 dev dep (8 deps, 9 dev deps, peer dependency).
• What will the effect be on the bundle size of our code? None because it's a dev dependency, which means it won't be included in the app bundle.

[melvin-bot]

📣 @LorenzoBloedow! 📣
Please report bugs or suggest features in the #expensify-open-source Slack channel, don't directly open issues in this repo!
Instructions here to join the channel 📖

[melvin-bot]

Triggered auto assignment to @arosiclair (AutoAssignerAppLibraryReview), see https://stackoverflowteams.com/c/expensify/questions/17737 for more details.

[melvin-bot]

New Library Review

• Are all the answers in the main description filled out properly and make sense?
• Who maintains the library and how well is it maintained?
• How viable are the alternatives?
• Should we build it ourselves instead?

Once these questions are answered, start a thread in #engineering-chat, ping the @app_deployers group, and call for a vote to accept the new library. Once the vote is complete, update this issue with the outcome and procede accordingly. Here is a sample post:

Hey @app_deployers,

There is a request to add a new library to App that we need to consider. Please look at this GH and then vote :+1: or :-1: on accepting this new library or not.

GH_LINK

[LorenzoBloedow]

Here's the Slack thread.

[arosiclair]

This seems like a simple change. Can you just write a test that verifies the view's scroll is disabled appropriately? I don't think it's really necessary to simulate a scroll event.

[LorenzoBloedow]

Can you just write a test that verifies the view's scroll is disabled appropriately?

It's a Safari-only bug, so we need to run the test in Safari. Currently from what I've seen we can only run these on native and Applause handles the web tests with E2E.

Also, checking the state to see if it's disabled would be testing implementation details which goes against these testing guidelines.

More context on this other Slack thread.

Please let me know if I'm missing something and we have an environment for testing on the web :)

[arosiclair]

Also, checking the state to see if it's disabled would be testing implementation details which goes against these testing guidelines.

I'm suggesting something like 2‍⃣ in the best practices section basically - render the component with no items and then verify the scroll is disabled. That should verify your fix is working on all platforms. Does that work?

[LorenzoBloedow]

What I'm trying to figure out is how to execute this test on a browser (DOM) environment. The proposed library simulates that. When running the tests with npm run test I'm only seeing the native version of the emoji picker being executed because we don't have a DOM environment.

But I just realized this is not about testing on a specific browser as that's E2E, so please ignore anything I said about testing on Safari.

I also realized the issue I'm trying to write UI tests for doesn't need this library, however, I still think we'd benefit from having it as some components seem to have logic that only happens in a browser, such as this.

But I couldn't find many that have much web-specific logic to test, and we still have a lot of native/general tests to write, so I guess this proposal, if it makes sense, isn't needed for now, so I'll just close it, I apologize for the noise.