Skip to content

Enable partial matching #546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

AugustinLF
Copy link
Collaborator

Summary

Follow up of #489, I'm trying to make the migration from @5.X to @7.X in a fairly large project. Another missed breaking change is that the current implementation doesn't permit "partial matches", as is render(<Text>Hello World</Text>).getByText('Hello') will throw. We have a lot of tests relying on this pattern (which is also the way web behaves). In this PR I fixed that.

This is technically a breaking change since some people might rely on getByText throwing in this case. But I do believe that we should seek for an API as close as possible from @testing-library/react.

Test plan

I added several tests that should cover the different edge cases related to this change.

if (text === textToTest) {
return { exact: true };
} else {
if (textToTest.includes(text)) {
Copy link
Collaborator Author

@AugustinLF AugustinLF Sep 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using includes here posed a lot of problem since it means that the parent nodes will also match. Hence the significant update to the logic.

@@ -95,13 +112,46 @@ const getNodeByTestId = (node, testID) => {
: testID.test(node.props.testID);
};

export const nonErroringGetByText = (instance: ReactTestInstance) =>
function nonErroringGetByTextFn(text: string | RegExp) {
const matchingInstances = instance.findAll((node) =>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we switch from find to findAll, the implementation doesn't throw anymore if no match is found. So I updated that so we can still use this implementation in queryByText (which shouldn't throw).

@thymikee
Copy link
Member

How does it relate to #541?

@AugustinLF
Copy link
Collaborator Author

I believe that actually #541 is a more correct approach. Now that I'm digging in the textMatch option I realise that some of my assumptions seem to be incorrect. I'm going to close my PR for now and will follow #541. If needed I'll come back to it. Sorry for the trouble.

@AugustinLF AugustinLF closed this Sep 14, 2020
@thymikee
Copy link
Member

Don't be sorry! Too bad you didn't see the PR earlier. However, if you feel like it, I'd appreciate reviewing that PR to make it right :)

@AugustinLF
Copy link
Collaborator Author

I'm on it, will run my tests against that implementation to see if it behaves as I'd expect it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants