'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.

[kristianfreeman]

Realize this is closed, but giving this a 👍 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

[epb-644]

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

[lonix1]

Also bitten by this. If someone actually finds a plugin/workaround for this, please let the rest of us know? Thanks!

[PatrikValkovic]

I would also like to ask for this feature and reopen the issue. Writing to.be.falsy instead of not.to.be.ok makes sense (especially for error checking as mentioned above) and as it should be easily implemented above not.ok, I don't see the reason why not to include it in the library. Especially when chai targets the readability with its be, to, should, etc., it makes perfect sense to use falsy and truthy as well.
@logicalparadox

[JakobJingleheimer]

@logicalparadox there are several instances of assertion aliases already in Chai. This seems a pretty reasonable alias. I have to google "chaijs truthy" (or "chaijs falsy") every time.

On a related note: "ok" is very unclear. "ok" literally means "all right" (as in, "no problems"), so one would reasonably see "ok" and think "doesn't throw".