Live data from Hacker News

From Karma to Mocha, with a taste of jsdom

medium.com

11–20 of 20 posts

Re: From Karma to Mocha, with a taste of jsdom

#11
post #6

Karma and Mocha don't do the same thing, so this comparison is weird. Karma is a test runner. Use Karma to launch and run your tests in real browser instances. There is no better tool available for doing this. Mocha is used to actually create your test suite. It's great at describing how your tests should run, with stuff like before/afterEach, it.only, describe.skip, etc. Use Mocha to describe which tests you want to…

As you can see from the article, this is not truly a comparison between Karma and Mocha, but I wanted the title to be intentionally provocative, to sparkle some discussion around the topic :)

We use test-automation for real browser testing but prefer to rely on quick and functional unit-testing, thus the choice to go with jsdom.

Regarding the community, you're right, there's a `karma-something` for every need. However, mocha is pretty popular too, and getting momentum by the day. Also the fact that it simply runs on Node makes it quite easy to obtain what you want without extra plugins (e.g. coverage).

Re: From Karma to Mocha, with a taste of jsdom

#12

It seems that the majority of the benefit was replacing a browser instance (PhantomJS launched via Karma) with a virtual-DOM (jsdom). Karma shines when you're running integration/e2e tests against _real_ browsers, especially IE.

Integration tests are better handled on CI by test-automation tools like NightwatchJS or Capybara, imo.

Using Karma and Phantom for unit-testing it's just overhead to me.

Re: From Karma to Mocha, with a taste of jsdom

#13

It feels like there's a little bit of comparison mismatch here - I would equate Jasmine to Mocha, as they're both test frameworks, whereas Karma is a test runner. Mocha comes with a test runner OOTB, but you can also run Mocha tests with Karma. One of the things I like about Karma is the ability to run the test suite in a number of browsers. We run our suite in Firefox, Chrome and PhantomJS as part of the CI setup. I…

Of course the comparison between Karma and Mocha is weird, that's why the entire Karma/Jasmine/Phantom combo and Mocha/jsdom is mentioned. There's one piece missing in the Mocha/jsdom combo actually, the assertion library, and we use `unexpected` for that purpose.

Re: From Karma to Mocha, with a taste of jsdom

#16
post #2

Thanks for the good read, very enlightening. But, I thought the choice of React as an example was interesting since it already provides test utilities. Any specific reason you aren't using these or were they just omitted for simplifying a blog post? https://facebook.github.io/react/docs/test-utils.html

The react test utils work in combination with jsdom. For example, TestUtils.renderIntoDocument will use jsdom as the document.

There is a facebook-sponsored test framework called "jest" that is more akin to mocha or jasmine, but of those three frameworks it is the worst in my opinion. It's absurdly slow, poorly supported, and it mocks all imported/required modules by default which causes me more problems than it solves.

Re: From Karma to Mocha, with a taste of jsdom

#17
jsdom is great, I have nothing but respect and admiration for its developers. But ultimately, it's not a very good representation of how browser implementations of the DOM really behave, and it's quite lax about letting you do things that won't work in browsers. So often your tests just end up testing that your code works in jsdom. Phantomjs has its own issues but is at least based on a real browser engine.

There are some nice tools that allow you to pipe JS to them for execution. For jsdom, there's jsdom-eval, and for phantom there's ghostface.

Lastly, I don't think there's much point casting about for the exact right assertion library or test harness framework. The important thing is the environment your tests run in, and how your tests are written of course. It doesn't matter if you're calling `assert(realValue, expectedValue)` or `expect(realValue).toBe(expectedValue)`, etc.

Re: From Karma to Mocha, with a taste of jsdom

#19

I used to use Karma / Mocha... Now I advocate that people use Tape. There's a great article [0] about tape, which I'd suggest giving a read! If you want to run your tests on all the browsers, you can use zuul [1], which is also dead simple to use! [0] https://medium.com/javascript-scene/why-i-use-tape-instead-o... [1] https://github.com/defunctzombie/zuul

tape is a good pick, thanks!

i've been using mocha, just b/c it's the most popular, and tho it's not bad, i dislike that even in programmatic[.] usage, one generally doesn't import tests as a "module" object. somehow it just doesn't jibe w/ notions of code reuse, even if it hasn't become much of a problem in practice. anyway, i got curious about how to do this, started reading the source, and at a cursory glance, it looked like reading in tests as files was baked in pretty deep.

[.]https://github.com/mochajs/mocha/wiki/Using-mocha-programmat...

Re: From Karma to Mocha, with a taste of jsdom

#20
post #11
post #6

Karma and Mocha don't do the same thing, so this comparison is weird. Karma is a test runner. Use Karma to launch and run your tests in real browser instances. There is no better tool available for doing this. Mocha is used to actually create your test suite. It's great at describing how your tests should run, with stuff like before/afterEach, it.only, describe.skip, etc. Use Mocha to describe which tests you want to…

As you can see from the article, this is not truly a comparison between Karma and Mocha, but I wanted the title to be intentionally provocative, to sparkle some discussion around the topic :) We use test-automation for real browser testing but prefer to rely on quick and functional unit-testing, thus the choice to go with jsdom. Regarding the community, you're right, there's a `karma-something` for every need. Howeve…

"wanted the title to be intentionally provocative"

Click bait adds no value to the discussion.

There's no either/or when it comes to karma/mocha. As the commenters above mentioned, it's best to use both. Mocha for quick unit testing, karma for in-browser testing.

In-browser testing can be automated to run on a wide range of browsers and platforms using integration tools such as Browser Stack.

By faking the DOM, you remove nerf the greatest advantage of client-side integration testing. Checking functionality under realistic circumstances.

Post reply on HN