Chai: 'truthy' and 'falsy' should be chainable properties.

[jamestalmage]

Especially since the description for ok actually uses the word truthy.

[jamestalmage]

I'm happy to submit a PR if people are amenable to the idea.

[logicalparadox]

This seems redundant for core as x.should.be.truthy would be the same as x.should.be.ok AND x.should.be.falsy would be the same as x.should.not.be.ok. Feel free to implement as plugin.

[jamestalmage]

Consider this fairly common scenario: Some API's return a result object which may or may not have a property error. The presence of said property indicates that there was .... an error. So while writing a test where I expect an error, I might do something like this:

var result = someActionThatShouldProduceAnError();
expect(result.error).to.be.ok;

That is potentially confusing to someone who isn't familiar with chai. The following is easier to understand.

expect(result.error).to.be.truthy

If you google "javascript ok" vs. "javascript truthy", I think it shows that truthy is a better choice than ok.

Chai is full of redundant syntax, so rejection on that basis seems arbitrary.

• above, gt, greaterThan
• equal, equals, eq
• include, contain

I could be persuaded to give up on falsy in favor of not.truthy, but I'd ask you to reconsider rejecting the idea in its entirety.

[signalnerve]

Realize this is closed, but giving this a :+1: because I also think that "truthy"/"falsy" is more clear than "ok".

[juuxstar]

OMG +1 for this. just ran into this as well. We've been using truthy and falsy throughout our tests and just discovered that they're not actually passing or failing. And chai doesn't complain at expect(...).to.be.truthy. I would imagine it should at least throw some type of WTF is truthy error. Talk about _principle of most surprise_.

[franciscop]

@jamestalmage came exactly to comment on the same. On my code:

expect(res.error).to.be.not.ok;

Where this would be a lot more clear:

expect(res.error).to.be.falsy;

[mikeabiezzi]

@logicalparadox +1 on the intuitiveness of .to.be.truthy and .to.be.falsy

[eddieburns55]

+1 we've had a lot of confusion on this in our codebase