Upgrade specs to use chai and chai.assert

[shellscape]

Working with the linter refactor and having to do a lot with specs, I'm feeling pretty limited by assert's small set of functions. Since the recommended accompanying bdd lib for mocha is chai, we should consider moving to that post-1.0 release.

[kokarn]

Sounds good. I'm not that versed with testing yet but I have had the feeling that it's quite limiting so i'll just take your word for it ;)

[jwilsson]

I've never used Chai either but it looks interesting, we should definitely consider it.

I'll take a closer look at it as well.

[CITguy]

Chai is nice. I use it daily.

[shellscape]

Yeah we're actually transitioning from jasmine to mocha+chai here. Changing specs platforms are a hard sell since it requires a lot of effort for little gain (if the specs are already working).

[kokarn]

Lucky we don't have a budget then. I like chai more than mocha because of the name. That's 100% approval 👯

[jwilsson]

I might have some time this weekend to take a look at this. I'll make sure a new branch is up for it at least.

[shellscape]

Any thoughts on using gulp for that in tandem with the switch? (We're just going a TON with gulp lately, and I'm really loving it, so I had to ask)

[jwilsson]

Just out of curiosity, why should we use Gulp? We're basically running two tasks (lint and test), Gulp just seems a bit much.

[shellscape]

This is a decent article from a former employer: http://appendto.com/2015/08/why-use-a-task-runner-like-gulp/ - the last paragraph nails it though. We're actually doing 4 things: coverage (doesn't look like it's enabled, but it should be!), linting js, linting js code style, running mocha. What you end up with is all of your tasks in one file. mocha.opts goes away, and goes into the gulpfile. the scripts section of package.json gets changed to "test":"gulp". It also provides uniform output (it's important to me, but I know I'm silly) And the wealth of plugins offers really quick integration of future tasks.

It's an alternative. I'd dare say the experience is better than combining separate tools manually. But again, personal preference. (We've heavily invested in it, driving all of our front end tooling for the org, and if you're curious: https://github.com/gilt/gilt-swig.)

[jwilsson]

A coverage report is generated on Travis and you can do it manually with npm run cover (it will print some errors since it can't connect to Coveralls) but you'll get a HTML report in the coverage dir.

I've always thought of Gulp as a front-end build tool (that's what I'm using it for all the time, btw) but I guess there's nothing stopping you from using it in this type of project. I'm not completely sold just yet (gonna let it mature for a few days) but we'll keep the discussion open. @kokarn thoughts?

[shellscape]

Didn't mean to take this one too far off the rails of the chai usage :)

[kokarn]

I like grunt/gulp doing a as much as possible.
I use it to run pretty much anything in some projects.
It is defined as a task runner and that's exactly how I use it.
Why should I do something if grunt/gulp can do it for me? 💃

[jwilsson]

I thought about Gulp earlier today and figured we could use it to check for stray console.log()s as we talked about in #88. I'll try and work something out and send a PR later tonight.

[shellscape]

👍