toMatchElement() does not behave like matchesElement()

[kumar303]

I have a component that does something like this:

componentDidMount() {
  this.refToTextarea.focus();
}

This test with enzyme-matchers fails:

it('focuses the textarea', () => {
    const root = mountMyComponent();
    expect(root.find('.MyComponent-textarea'))
      .toMatchElement(document.activeElement);
});

I see:

    Expected actual value to match the expected value.
    Expected:
     <textarea />
    Actual:
     <textarea className="MyComponent-textarea" onInput={[Function]} name="review" value={[undefined]} placeholder="The placeholder text." />

With a vanilla Jest/enzyme assertion the test passes:

it('focuses the textarea', () => {
    const root = mountMyComponent();
    expect(
      root.find('.AddonReview-textarea')
        .matchesElement(document.activeElement)
    ).toEqual(true);
});

Shouldn't these both behave the same?

I'm running tests in Node with mocha. Versions:

Node: v6.10.3
Jest: 21.0.2
enzyme-matchers: 3.8.3
jest-enzyme: 3.8.3
jest-environment-jsdom: 21.0.2
  └─ jsdom@9.12.0

[blainekasten]

That's a really good question...

We use .debug() on the nodes to compare the output strings for some reason. I can't remember why we do that. It seems like the wrong idea..

I wonder if @finnigantime remembers why that approach was desired.

[typeofweb]

Any news on this?

[ruyasan]

I too would like to know - having to match all props is not always ideal

[finnigantime]

Hey, sorry for late reply. See more context in #95. I think ignoring props is just a missing option (and should probably be the default option). I added the option to ignore props to enzyme's debug() in enzymejs/enzyme#961 but I guess I never came back and plumbed through the ignoreProps option here. So someone should be able to easily plumb that through.

I also agree with @blainekasten that comparing strings is not ideal - comparing structured data objects may be better than comparing strings from a maintainability point of view. One advantage of comparing strings is the diff is obvious and very human readable which is helpful when the expect fails.

[finnigantime]

I cannot get to this right now, but am happy to code review if someone wants to put up a fix - should be fairly straightforward. Otherwise I can take a stab at it when I get some more time.