Can't getByText for component that returns a fragment

[joebourne]

Describe the bug

Using the T component from @transifex/native, I am unable to getByText() any child component of <Text /> whose return is simply a fragment or string.

Expected behavior

The inner text of the fragment is found by getByText and returned.

Steps to Reproduce

import React from 'react';
import { Text } from 'react-native';
import { render } from '@testing-library/react-native';

// This is mocking T from @transifex/react that has similar but more complex functionality
function T({ _str }) {
  return _str; // same if returning <>{_str}</>
}

function Test() {
  return (
    <Text>
      <T _str="My String" />
    </Text>
  );
}

describe('Test', () => {
  it('should render the correct text', () => {
    const { debug, getByText, toJSON } = render(<Test />);

    debug();

    console.log(toJSON());

    expect(getByText('My String')).toBeTruthy();
  });
});

Output of console.log(toJSON()) is { type: 'Text', props: {}, children: [ 'My String' ] } and output of debug() is

<Text>
  My String
</Text> 

Versions

npmPackages:
@testing-library/react-native: ^8.0.0 => 8.0.0
react: ^16.13.1 => 16.14.0
react-native: ~0.63.4 => 0.63.4

[thymikee]

Does it happen on 9.0.0-alpha.0?

[joebourne]

Thanks for the quick reply. Just tried and still happens on 9.0.0-alpha.0.

[AugustinLF]

This should be fixable. There are two cases to consider here:

• <Text><>Hey hey</></Text>
• <Text>Hey <>hey</></Text>

The first case is the one you raised, and is probably simpler to fix, and if we can, I don't see a reason why we shouldn't. The second is actually trickier, because on purpose we don't match across several react node, but it does make sense to consider that fragments should be ignored.

Edit: There actually seems to be a PR intending to fix this behaviour

[joebourne]

@AugustinLF I found the PR (#663) and it seems to be stale. Do you have any inside info on why it was dropped?

[AugustinLF]

The author of the PR has just been pinged, if they're not available anymore I guess we should be able to pursue the work on their PR.

[joebourne]

Thanks @AugustinLF - will monitor the PR 😊

[Alvindelito]

I have created a new PR (#883) to continue off of PR(#663) with the current up-to-date repo.

[thymikee]

Closed via #934