Proposal: .either.some.or.someElse

Would be nice to have .either as a delimiter and .or as finalizer of assertion chain.

Something like:

.to.be.equal('five').either.an('object').or.a('number')

There could be just one .or. And as many as need .eithers.

What you say?

[meeber]

I would strongly urge you to reconsider how you’re structuring your tests rather than write a plugin for adding or functionality.

If you find yourself needing or in your tests, it suggests one of two things:

1. Your tests are non-deterministic. In other words, each time you run your tests, you potentially get different results based on external conditions or pseudo-randomness. Rather than write tests that attempt to handle varying results by using or, I’d advise refactoring your tests, using test doubles as needed, in order to make your tests deterministic. The goal is for your tests to produce the exact same result each time they’re run. And then, as @keithamus exemplified in his first reply, a separate test should be written with different inputs (or different test doubles) in order to validate that the expected result is produced under each set of circumstances. Here’s a pretty good resource on this topic: http://martinfowler.com/articles/nonDeterminism.html
2. You’re trying to reuse an assertion for multiple test cases. I understand the allure of DRY, but a certain degree of repeating yourself is necessary when it comes to writing tests. In @thomasvanlankveld’s example, I’d recommend writing two completely separate tests, one that sets up the “post deleted” conditions, and then tests specifically that the desired outcome is produced, and then one that sets up the “post authorship changed” conditions, and then tests specifically that the desired outcome is produced. Even though both tests are testing identical outcomes, each test should be completely independent; they shouldn’t reuse the same assertion, since that would require the assertion to be able to handle multiple scenarios with or.

[keithamus]

tell consumers how to write their tests

That’s pretty much how chai works - and I think it is indeed part of chai’s responsibility to guide you into writing “correct” tests (or at least, avert you from writing incorrect ones). We also have limited resource and have to carefully curate what comes into core - this means we have a desire to keep core focussed on, well, core stuff. An either assertion breaks away from Chai’s core model, which stops us being focussed.

Probably we can make a plugin for either-or?

I think this is exactly the mindset I’d like for us to be after. In an ideal world - I’d like for chai users to create plugins for all the assertions they want, and chai-core periodically vacuums up the ones 90% of users install. Plugins become useful to either A) pick up domain or framework specifics (e.g. chai-react) or B) break out of chai’s core model, for better or worse (chai-as-promised, chai-things, and the theoretical either-or you talk about).