Skip to content
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.

Sign up for GitHub

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

Jump to bottom

toMatchElement() does not behave like matchesElement() #163

Closed
kumar303 opened this issue Sep 28, 2017 · 5 comments
Closed

toMatchElement() does not behave like matchesElement() #163

kumar303 opened this issue Sep 28, 2017 · 5 comments
Labels
question

Comments

@kumar303
Copy link

kumar303 commented Sep 28, 2017 •
edited
Loading

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
Copy link
Collaborator

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
Copy link

Any news on this?

@ruyasan
Copy link

ruyasan commented Jan 24, 2018

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

@finnigantime
Copy link
Contributor

finnigantime commented Jan 24, 2018 •
edited
Loading

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
Copy link
Contributor

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.

@finnigantime finnigantime mentioned this issue Jan 28, 2018
Merged
@brennancheung brennancheung mentioned this issue Jun 19, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kumar303 @finnigantime @typeofweb @blainekasten @ruyasan