Breaking change with undefined in 0.7.0?
ZebraFlesh opened this issue · 7 comments
The fix for handling undefined arguments on 0.7.0 doesn't seem like a fix so much as a breaking change. A lot of the examples are now incorrect. For example, the attr example has the line:
expect(wrapper.find('span')).to.have.attr('id')
But in 0.7.0, that will fail with AssertionError: expected the node in <Fixture /> to have a 'id' attribute with the value undefined, but the value was 'child'. Is this behavior intended?
I'm seeing a few failures after upgrading. They're in tests of the form expect(wrapper).to.have.prop('foo') and expect(wrapper).to.have.attr('foo').contain('some value').
The following should still work:
expect(wrapper.find('span')).to.have.attr('id')If it does not that is definitely a bug in the new code and it should be addressed. This was introduced in #152 any chance you can look into creating a PR with a fix?
Nope, definitely doesn't work with 0.7.0: it's seeing the absence of a second argument as undefined and using that for the expectation.
I'm a bit over-committed right now to offer up a PR. :(
@ZebraFlesh I just ran into something similar. Can you take a look at #180 and see if it's the same issue that you're explaining here? Also, could you try out #181 and/or #182 to see if they resolve your issue.
That's certainly consistent with how we use chai-enzyme: every test fixture we have that uses chai-enzyme does the following:
import chai from 'chai';
import chaiEnzyme from 'chai-enzyme';
chai.use(chaiEnzyme());
@ZebraFlesh okay, then either of those two PRs should address your issue. Hopefully the team here will accept one and release a new version soon!
@ZebraFlesh can you confirm if this is still an issue in 0.8.0
Looks like this is fixed in 0.8.0. Thank you!