Page MenuHomePhabricator

[Cashtab] Improve and standardize CreateToken tests
ClosedPublic

Authored by bytesofman on Feb 18 2024, 22:17.

Details

Reviewers
emack
Group Reviewers
Restricted Project
Commits
rABC11b8e217b690: [Cashtab] Improve and standardize CreateToken tests
Summary

T3444

Use standardized wrapper for CreateToke and CreateToken tests. Refactor and improve tests to work with new wrapper.

Test Plan

npm test

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

no data-testids, pointerevents issue

emack requested changes to this revision.Feb 19 2024, 07:36
emack added a subscriber: emack.
emack added inline comments.
cashtab/src/components/Etokens/__tests__/CreateToken.test.js
44 ↗(On Diff #45371)
48 ↗(On Diff #45371)
79–88 ↗(On Diff #45371)

What's the reason for .findByText() using await and .queryByText() being wrapped inside a waitFor?

102 ↗(On Diff #45371)

Also in contrast to above, this queryByText of an element not expected to be rendered is not wrapped in a waitFor.

cashtab/src/components/Etokens/__tests__/CreateTokenForm.test.js
45 ↗(On Diff #45371)
49 ↗(On Diff #45371)
123 ↗(On Diff #45371)

Is there an advantage to using this over getByText()?

This revision now requires changes to proceed.Feb 19 2024, 07:36
bytesofman marked 6 inline comments as done.

version bump, recommended improvements

lint

cashtab/src/components/Etokens/__tests__/CreateToken.test.js
79–88 ↗(On Diff #45371)

screen.findByText is async. When you can use this one, it is preferred vs using the await waitFor() -- and react testing library eslint plugin will pick it up and recommend you use await screen.findByText

findByText though, similar to getByTestId, should only be used when you do expect to find it.

Still tho a bad implementation in this case. we do not need or want the waitFor for something to not be in the document, unless it is something we are expecting to disappear based on a state change or some other user action on the page. So, removed the waitFor here.

102 ↗(On Diff #45371)

This is the right approach. Duplicated above.

cashtab/src/components/Etokens/__tests__/CreateTokenForm.test.js
123 ↗(On Diff #45371)

From the docs, this is the most recommended way to find a button. In this case, you are only looking for buttons with text content regex matching Create eToken.

getByText, you are looking for all elements with text, including non-buttons.

This revision is now accepted and ready to land.Feb 20 2024, 08:19