Enzyme matchers do not match correctly children of React Fragments

[astorije]

Describe the bug

This is a dedicated issue corresponding to a comment I initially left at #1213 (comment).

When using React Fragments, it looks like only the first child is being picked up by the matchers.

To Reproduce

Assuming the following code:

const Foobar = () => (
  <>
    <div>Foo</div>
    <div>Bar</div>
  </>
);

And the following test:

describe('<Foobar />', () => {
  test('should include Foo and Bar', () => {
    const wrapper = mountWithIntl(<Foobar />);

    expect(wrapper).toIncludeText('Foo');
    expect(wrapper).toIncludeText('Bar');
  });
});

Bar simply does not get rendered:

 FAIL  test/src/Foobar.test.jsx
  ● <Foobar /> › should include Foo and Bar

    Expected <IntlProvider> to contain "Bar" but it did not.
    Expected HTML: "Bar"
    Actual HTML: "Foo"

       8 |
       9 |     expect(wrapper).toIncludeText('Foo');
    > 10 |     expect(wrapper).toIncludeText('Bar');
         |                     ^
      11 |   });
      12 | });
      13 |

      at Object.test (test/src/Foobar.test.tsx:10:21)

mountWithIntl is a simple wrapper that adds an IntlProvider (from react-intl) to help us deal with i18n in our tests. If I remove it and replace with bare mount, I get:

  ● <Foobar /> › should include Foo and Bar

    Trying to get host node of an array

       7 |     const wrapper = mount(<Foobar />);
       8 |
    >  9 |     expect(wrapper).toIncludeText('Foo');
         |                     ^
      10 |     expect(wrapper).toIncludeText('Bar');
      11 |   });
      12 | });

I get the same results if I swap the <>...</> shorthand with <React.Fragment>...</React.Fragment>.

However, if the code is:

const Foobar = () => (
  <div>
    <div>Foo</div>
    <div>Bar</div>
  </div>
);

then now the tests pass fine.

For what it's worth, the built code for Foobar (built with tsc) looks like:

const Foobar = () => (React__default.createElement("div", null,
    React__default.createElement("div", null, "Foo"),
    React__default.createElement("div", null, "Bar")));

Expected behavior

I'm very confused as Enzyme 3.5 has Fragment support. Do you see something just obviously wrong above?

I'm wondering if the TypeScript compilation doesn't compile into something that's causing #1178. Or I'm just doing something wrong...

Additional context

• enzyme@3.5.0
• enzyme-adapter-react-16@1.3.0
• enzyme-matchers@6.0.4 and jest-enzyme@6.0.4 (outside of this project I know)
• TypeScript v3.0.1
• Jest and ts-jest

[ljharb]

Since toIncludeText isn't part of enzyme itself, can you try with expect(wrapper.text()).toInclude('Foo') etc? What's wrapper.text() here?

[lencioni]

I'm also curious if reversing the order of the assertions to be

expect(wrapper).toIncludeText('Bar');
expect(wrapper).toIncludeText('Foo');

will cause the same assertion to fail, i.e. is this always failing on the second assertion or on the text of the second child?

[ljharb]

That’s also a very good question. There’s some issues with statefulness, shown in #1781, that may be related, if so.

[ljharb]

I'm able to reproduce this for mount only, regardless of order.

[ljharb]

I've pushed up failing test cases; the issue seems to be that the adapter's nodeToHostNode only returns the first node - even though for fragments, there's multiple. Additionally, there's no way in the tree to identify that there's a fragment.

I'm not sure what the best option is - perhaps including the fragment in the tree and flattening it only where needed? or perhaps overloading nodeToHostNode to return an array, or better, a DocumentFragment, in this case? cc @madicap

[astorije]

@ljharb, sorry for the delay! It seems to me that you have already identified the source of the issue, but I'll still reply here with what I can figure out in case that's useful:

Since toIncludeText isn't part of enzyme itself, can you try with expect(wrapper.text()).toInclude('Foo') etc?

Note that I am highly unexperienced with Enzyme yet, and it's likely something it misconfigured on our end, but for some reason this gives me TypeError: expect(...).toInclude is not a function at the moment. I'm very confused why :/

What's wrapper.text() here?

By adding:

console.log('>' + wrapper.text() + '<');

I get:

  console.log test/src/Foobar.test.tsx:10
    >Foo<

I'm also curious if reversing the order of the assertions to be [...] will cause the same assertion to fail, i.e. is this always failing on the second assertion or on the text of the second child?

Reversing the order of the assertions causes the Bar one to change. In other words, both assertions fail individually.

---

Let me know if there is anything else I can test, or if there is a workaround we can apply for now (replacing the <> fragment in the code side with <div> to keep the tests happy is not an option unfortunately).

Thanks! 🙏

[ljharb]

I don't think there's a workaround at the moment.

[madicap]

@astorije I'll try to see what I can do about this over the weekend

[astorije]

That's great to hear, thanks @madicap!