Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Does not allow length checks on jQuery objects #21

Closed
lazd opened this Issue · 13 comments

6 participants

@lazd

We may need to test that an exact number of elements match a selector, and it seems chai-jquery breaks previously methods of doing this. Previously, we were doing:

expect(el.find('.modal-footer button')).to.have.length(2);

But this fails when chai-jquery is included:

'1' is not a function (evaluating 'expect(el.find('.modal-footer button')).to.have.length(2)')

In order to get our tests to run, we had to change it to:

expect(el.find('.modal-footer button').length).to.equal(2);

Is there a better recommended way of accomplishing this using chai-jquery? have is not sufficient as it only tests if at least one descendant is present.

@jfirebaugh
Owner

I don't think this is fixable without removing support for expect($(...)).to.have(selector). That requires that the have property return a function, and a function's length property is not writable.

What I could do is support this:

expect(el).to.have(2, '.modal-footer button');

Would that be satisfactory?

@jfirebaugh
Owner

BTW, you can also do:

expect(el.find('.modal-footer button')).to.have.lengthOf(2);

@RStankov

My pull request #22 will give the option todo:

expect(el.find('.modal-footer button')).to.have.size(2);
@domenic
Owner

This should be fixable using Chai's addChainableMethod...

@jfirebaugh
Owner

@domenic Can you elaborate? My analysis was that if have is a function, there's no way for have.length(n) to also work, since a function's length property is not writable.

@domenic
Owner

@jfirebaugh ah right :(. didn't read very well...

@domenic
Owner

Workaround:

expect(el.find('.modal-footer button')).to.be.of.length(2);
@jfirebaugh
Owner

Nice, I'm going to note this issue in the README and suggest that as the official workaround.

@jfirebaugh jfirebaugh closed this
@asmblah

This is a shame, this is a blocking issue that has stopped me from using this in a project already using Chai and a lot of existing expect(...).to.have.length(...); :(

I would suggest replacing the expect(...).to.have(...); syntax with expect(...).to.have.descendant(...); or expect(...).to.have.descendant.matching(...); or something similar if it was earlier in the process to avoid breaking existing Chai behaviour.

@lazd

@asmblah: Is it that neither of the workarounds meet your use case, or that you would prefer a more expressive statement?

Although they're not gorgeous, either of these workarounds should unblock you:

expect(el.find('.modal-footer button').length).to.equal(2);

Or

expect(el.find('.modal-footer button')).to.be.of.length(2);
@asmblah

Hi @lazd,

Thanks for the response. No, the issue is that the test codebase already uses expect(<array>).to.have.length(7); etc. in *many* places which are then broken when including the chai-jquery library. I understand that alternative syntaxes exist but do not want to change all those references.

What I meant was, if the expect(...).to.have.* syntax hadn't been broken by chai-jquery, instead being implemented as expect(...).to.have.descendant(...); or similar, then I could have made use of the library.

Would a pull request with changes to support a config option switching on/off the overriding of have with a function and instead supporting an expect(...).to.have.descendant(...); (or similar) be acceptable?

@akalman

Since chai-jquery doesn't seem to use have as a function anymore, is this fixable now?

@jfirebaugh
Owner

Removing the overload of have was the fix; expect(el.find('.modal-footer button')).to.have.length(2) should work in 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.