Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

The example code for present() is misleading

See original GitHub issue

.find() returns ShallowWrapper which is alway present no matter what. – http://airbnb.io/enzyme/docs/api/ShallowWrapper/find.html

expect(wrapper.find('.foo')).to.exist; // passes
expect(wrapper.find('.foo')).to.present(); // passes

Instead existence check should look like

expect(wrapper.find('.foo').length).to.equal(1); // fails
expect(wrapper.find('.foo').html()).to.exist; // fails

Issue Analytics

State:
Created 7 years ago
Comments:5 (1 by maintainers)

Top GitHub Comments

1reaction

droartycommented, Jul 21, 2016

So I am happy to edit the documentation but I still have a question about this issue. As far as I can tell from the code, .present is an alias for .exist which calls wrapper.isPresent(). But to use the matcher you don’t include the parenthesis in either case. So:

expect(wrapper.find(".my-class")).to.exist  // Passes
expect(wrapper.find(".my-class")).to.be.present  // Passes
expect(wrapper.find(".my-class")).to.exist()  // Fails
expect(wrapper.find(".my-class")).to.be.present()  // Fails

Calling them like methods gives the error:

undefined is not a constructor (evaluating 'expect(wrapper.find(".my-class")).to.be.present()')

So I assume the documentation should reflect that. If this makes sense, I can go ahead and make the PR.

1reaction

ljharbcommented, Jun 3, 2016

Both of those are built-in chai matchers, and since they return objects, that’s correct. In other words, those are not the correct matchers to be using. You should use expect(wrapper.find('foo')).to.have.lengthOf(1) or similar.