It would be nice if expect(x).to.equal.true would throw an error

[joevennix]

Right now, expect(x).to.equal.true silently passes. Correct me if I am wrong, but accessing properties off of .equal never looks to be useful, so it would be beneficial to (forgetful) developers to have this raise instead of silently pass. This could be done with a fixed set of getters on equal that raise.

If my thinking is correct I will happily implement this feature for you folks.

[keithamus]

Hey @joevennix thanks for the issue.

It would be nice to have these kinds of properties raise an error - but I don't want to do it on a case-per-case basis, as that becomes a slippery slope, where we have hundreds of lines of code to protect users from mistakes.

Rather than that, we've been discussing the idea of using ES6 Proxies over in #407 which will generically catch on ALL of these kinds of errors. I'm going to close this one, in favour of furthering discussion in #407.

[joevennix]

@keithamu, love the idea of using ES6 proxies! I would have proposed that myself but wasn't sure what it would mean for supported browsers etc. Thanks for the quick response.

[joevennix]

@keithamus, does chai have an idea of a testComplete() hook? If so, you could perhaps implement this without proxies, by raising after the test when a expect() is called but an assertion was never actually performed.
(or just expose a expect.testComplete() function and users can opt to put it in a global afterEach()).

[keithamus]

There is no concept of this at the moment, and I doubt there could be - for starters when would the error throw? We've discussed the idea of counting assertions within chai - sort of like qunits expect(n) but Chai's architecture means a single assertion statement can make multiple assertions (e.g. to.have.property('foo', 1) asserts that there is a property, and asserts that it is equal to the 2nd arg, so 2 assertions in one statement).

Proxies are a solid option for property access, another option is trying to re-develop a solution for "jshint friendly assertions" (meaning no assertion properties like to.exist, only methods like .to.exist()).