Use chai in our tests

[epixa]

I propose that we start using chai with mocha, which lets us use chai.except and sinon-chai for more flexible and expressive test errors.

Better errors:

expect(myspy).to.have.been.called; // "Expected {...} to have been called, but wasn't"
// instead of
expect(myspy.called).to.equal(true); // Expected false to equal true

Custom Plugins:

// sort of uses chai-as-promised, otherwise totally made up, but you could make this happen
expect(mypromise).to.eventually.be.rejected.with(Boom.notFound());

Many plugins available to us right away: http://chaijs.com/plugins

It's really setup, and I'm happy to do it.

[kimjoar]

The one thing I hate about chai is this:

expect('test').to.be.undefied;

Nooothing happens and no errors because of a typo (undefied instead of undefined). Such pain. It also looks so un-JavaScript-y with all the .to.have.been.something.with.somethingelse.wtf, but that might just be me 😒 (I'll go rant somewhere else 💯)

Otherwise, totally agree on better error messages. It's very important when working with large amount of tests. I hate debugging for half an hour just because the error message was unclear. This is also why it's so important to actually see the test failing when you write it.

[epixa]

So what you're saying is... we need tools that allow for static analysis to reliably identify errors like typos. Sounds like another vote for es6 modules :P

[kimjoar]

That's just throwing more complexity at the problem ;) I'm thinking about something like this:

expect('test').to.be.undefined()

or, maybe even better with one of these:

expect('test').to(beUndefined)
expect('test').to(beUndefined())
expect('test').toBeUndefined()

Or something like that.

[epixa]

Understood. We could probably throw together that sort of behavior in a pretty simple plugin that adds method helpers instead of the default property helpers.

[kimjoar]

Oh, I forgot:

expect('test').toBe(undefined);

where toBe is just a === check. That would also catch the typo.

Some months ago I got so annoyed that I created my own https://github.com/kjbekkelund/expect-to ;) (But I'm absolutely not trying to "sell" this to Kibana — this was mostly to play around with ideas on how I would like a testing lib to work). Personally I might lean in the direction of https://www.npmjs.com/package/expect, but I absolutely realize the value in having chai with it's huge community. (So just consider just random ranting about testing and assertion frameworks in general 💯 Haven't found one I really liked yet.)

[spalger]

I've started using sinon's asserts when I'm verifying sinon stubs, mostly because they provide more readable error messages:

sinon.assert.calledOnce(obj.method);
// vs
expect(obj.method).to.have.propety('callCount', 1);
expect(obj.method.callCount).to.be(1);

[Bargs]

👍 Chai provides an assertion for deep equality and supports promises via chai-as-promised.

[simianhacker]

I'm +1 on chai... I've been using it for years (before I started working on Kibana) and I still use when I'm not working on this code base.

[bevacqua]

Guys why not use assert? BDD is the worst.

[scampi]

+1 on chai, also expectjs seems not to be maintained anymore (or very little...) Automattic/expect.js#100 Automattic/expect.js#151

[scampi]

Something I found out today: if you expect a method to throw an error, and the expectation is a string, then it will always pass:

expect(fn).to.throwError('correct message'); // pass
expect(fn).to.throwError('funky message'); // pass but shouldn't

However, if you use a regexp expression, it will assert as expected:

expect(fn).to.throwError(/correct message/); // pass
expect(fn).to.throwError(/funky message/); // fail

[cjcenizal]

I'm +100 for moving away from Expect.js, but I've found the Jasmine interface to be much simpler and easier to read than Mocha and Chai (https://jasmine.github.io/2.5/introduction).

Per @kjbekkelund 's earlier comment about asserting that something is undefined or making an assertion of strict equality, Jasmine offers both:

expect(a.bar).toBeUndefined();
expect(true).toBe(true); // strict equality
expect(1).toEqual(true); // loose equality

The interface is simpler, mostly by eliminating the pointless to object, and instead expecting you to either assert something by calling a method, or invert the assertion by prepending the method with the not property:

expect(foo).toThrowError("foo bar baz");
expect(foo).not.toThrowError("foo bar baz");

The interface also offers a rich number of assertions for increasing the readability of your assertions:

expect(0).toBeLessThan(1);
expect(1).toBeGreaterThan(0);
expect("bar room").toContain("bar");
expect({}).toBeTruthy();
// etc...

As a test runner, Jasmine simplified the interface to describe and it (no more context, which I find pretty confusing/meaningless since it's just an alias to describe). There are setup and teardown methods of course.

As another benefit, you can use fdescribe to focus on any suites you like, even if they're nested or in separate files. You can also use xit to temporarily disable a test.

[timroes]

I think our current decision is to use Jest for testing. Can this issue be closed then, or do we discuss if we want to introduce another expect library inside Jest?

[epixa]

@timroes If you think an issue should be closed, go ahead and close it along with your rationale. It can always be reopened if necessary.

You're right, we want to move to jest, so this isn't necessary any longer.