Overriding '.be' causes incorrect usage to be silently ignored

[eventualbuddha]

Let's say you are new to Chai or you just forget all the matchers and how they work. You might think that this is how you check that something is the same as something else:

expect(1 + 1).to.be(2);

Without chai-jquery loaded this throws an error: TypeError: Property 'be' of object #<Assertion> is not a function. However, when chai-jquery is loaded and you run this again you will get no exception. This seems to be because of the be override that can be called as a function. The trouble is that when the object being asserted against isn't a jQuery object the assertion is simply a no-op.

I'm not sure how to fix this. My inclination is to simply remove the be override and tell people to use match, though that'd obviously break backward compatibility. If there's some way to determine that it is being called in the manner above and to throw an exception that would be best.

[theghostbel]

@eventualbuddha
"be" is just "dummy" word to make your assertions readable. If you'll open chai.js you could see

[ 'to', 'be', 'been'
  , 'is', 'and', 'has', 'have'
  , 'with', 'that', 'at'
  , 'of', 'same' ].forEach(function (chain) {
    Assertion.addProperty(chain, function () {
      return this;
    });

So, your code should be corrected and it will start looking like expect(1 + 1).to.be.equal(2); or even (1+1).should.equal(2); or expect(void(0)).to.be.undefined

[eventualbuddha]

@theghostbel yes, that's true. However, my point is that using .be incorrectly without chai-jquery results in an exception. That's good, since it lets new users know that .be(2) is not supposed to work. However, adding chai-jquery causes such incorrect usage to simply do nothing. This is a problem since anyone new to Chai's API might write expect(1 + 1).to.be(2) and, when it "passes", think it is correct.

If you are skeptical that this is a problem, try introducing Chai + chai-jquery on a project with 20+ active committers who are not in the same team or location and who have either zero or very little experience with either. Heck, even experienced Chai users could make that mistake, at least in doing a code review if not in writing it themselves.

So the question remains: how do we fix this? My suggestions as in the original post remain the same, but I'm no Chai expert so I'll defer to others on a real fix.

[theghostbel]

@eventualbuddha
Sorry, was inattentive. Problem is that after including chai-jquery .be() turns into real matcher and can lead into misunderstanding when used incorrectly.

Personally I don't know real fix at the time, but here are jsfiddles which reproduce the issue:

• with chai-jquery http://jsfiddle.net/the_ghost/679GH/
• without chai-jquery http://jsfiddle.net/the_ghost/3SCHU/

[eventualbuddha]

Yep, thanks for making the examples, @theghostbel. I think we'll probably end up forking and just removing .be() in our fork. Looking forward to a "real" fix.

[jfirebaugh]

Fixed in 270e8de.

[eventualbuddha]

Thanks, @jfirebaugh.