Error: Unable to find an element with text: "My text", while that text exist.

[retyui]

Describe the bug

getByText can find element if text render component with text as not children (See "Steps to Reproduce" below)

-const Trans = p => p.i18nKey; // can find (error)
+const Trans = p => p.children; // everything ok

Expected behavior

I see in debug output (see screenshot below) that text exists! But API can find it(
It should work properly!

Steps to Reproduce

    test('test',  () => {
      const { Text } = require('react-native');
      const { render } = require('@testing-library/react-native');
      const Trans = p => p.i18nKey;

      const screen = render(
        <Text>
          <Trans i18nKey="My text" />
        </Text>,
      );

      screen.debug();

      expect(screen.getByText('My text')); // Error: Unable to find an element with text: My text
    });

Screenshots

Output:

Versions

  npmPackages:
    @testing-library/react-native: ^7.2.0 => 7.2.0 
    react: 17.0.2 => 16.13.1 
    react-native: 0.66.4 => 0.66.4 
    react-test-renderer: 17.0.2 => 17.0.2 

[AugustinLF]

Yep, easy to reproduce, will try to figure out what happens but that should be fixable on our end.

[retyui]

@AugustinLF easy to reproduce but not easy to fix?

[AugustinLF]

I (or whoever's interested in) just need to take the time, but I don't think it should be very hard. I'll try to do that later this week, or next week

[Norfeldt]

@AugustinLF I know that this is a feature request. But is is possible to have the .debug() run automatically when a getBy* matcher fails? Recall react-testing-library had that and it was really useful to see how the component looks when debugging why it can't get a hold of it.

[pierrezimmermannbam]

Not sure this is easy to fix, the type of <Trans i18nKey="text"/> isn't string so the getChildrenAsText method is looking for strings in its children but it doesn't have any. For this to work it would require to be able to tell that it renders as a string but i'm not sure it's easily doable.

@retyui this can be fixed on your end by mocking the Trans component like this

jest.mock('./Trans', () => {
  const { Text } = require('react-native');

  return {
    Trans: (props) => {
      return <Text>{props.i18nKey}</Text>;
    },
  };
});

However if there is an effective way to fix this it would be very nice, or maybe it could be documented somewhere

[pierrezimmermannbam]

@AugustinLF I have found a solution but it's quite complex so I'm not sure it's something that should be done.
From what I've seen this can't be fixed if we use the type ReactTestInstance for getByText because there does not seem to be a way to know the component renders as a string, however it is doable by using the ReactTestRendererJSOn type. The thing is we also need to have access to the instance because it is what the query returns in the end. This is achievable by using the tree representation of type ReactTestRendererTree which combines the instance and a more json like modelization. This would however mean significant changes as it would almost completely change the way queries are done. I've been working on a draft pr and I think it would work and this type seems more appropriate for queries but I wanted to have your opinion first before spending more time on this

[AugustinLF]

@pierrezimmermannbam that sounds like an interesting approach. Working with a "simpler" representation, based only on the platform components also feels more testing-library like.

One thing we'll need to cater for is that people do rely on firing fake events for some events (see #918 , I've also had to do that for momentum events on FlatList) . Some scroll events, swipes, etc. don't play well with the fact that we're not really rendering the native components (while jsdom does fire the real DOM events).

I'm not sure how that last point would play with this rearchitecture, but I think we should either offer a fallback API (current state) or figure a way to improve the behaviour.

[pierrezimmermannbam]

@AugustinLF I'm not sure I understood your point about fake events. The changes I suggested would change the way queries are implemented internally but the api would remain the same as they would still return ReactTestInstance type so there shouldn't be any impact on the way fireEvent works. I'm not sure either how the issue if events not being supported could be fixed by using this approach but there are definitely things I'm missing here

[AugustinLF]

@pierrezimmermannbam the current implementation of fireEvent crawls the tree up until it finds a ReactTestInstance with a prop corresponding to the given event, and fires it. Even if that's not a real event/a custom component.

I'll add tests for those cases in main, this way we can easily make sure there's no regressions and you shouldn't have to worry about that.

Regarding tests, I'll go through the repo and make sure that we have the desired coverage before we merge your PR. Luckily our tests do test external APIs so internal rewrite would be safe, but I'll make sure we're not missing any cases.

[thymikee]

Regarding returning ReactTestInstance from queries – we considered replacing it with a QueryResult object or something, that would only give you access to specific fields instead of whole object. This is potentially breaking, but the direction where we'd like to go.

[pierrezimmermannbam]

@AugustinLF @thymikee I have made some progress on this, I opened a draft pr but I've hit an issue. The queries by text work fine using the json representation but there are some problems.

First, I still need to get the ReactTestInstance from the renderer.root because the instances in the ReactTestRendererTree type are in fact not of type ReactTestInstance and do not have parents which is problematic for the fireEvent. I was able to fix this by finding the ReactTestInstance matching the result of the search though I'm not entirely sure it is reliable.

The second issue is with within. For within to work, the queries return type and what is used to build the api need to be of the same type and I broke that by building queries with a ReactTestRenderer type and returning the same type as before. It would be doable to have the following type :

type QueryResult  = ReactTestInstance & { tree : ReactTestRendererTree }

However this would require to change not only the byText queries but all of them, which is more complex but shouldn't be too much of an issue if well refactored.
It would change the type of the api but not cause a breaking change as we'd be only adding a new field so it shouldn't be too problematic.

So before going further I wanted to have your inputs on this and make sure the implementation I started was what you also had in mind

[thymikee]

cc @mdjastrzebski