Karma, Testem, Non-Simplicity

2017 March 30

The other night I was introducing a Dom module in Forto and wanted to start some tests around this. The existing tests were using jest which relies on jsdom for in-memory in-javascript testing against the dom and so I was hoping I would be able to repurpose this existing code. But I quickly discovered that jsdom does not actually simulate dom layout making the tests I was interested in making impossible.

That meant I would have to:

  • install more test framework dependencies

  • run my existing jest tests apart from this new set of Dom integration tests

  • refresh my memory on another test system

Not ideal.

I tried to think of the most lightweight solution: headless testing. That is, I didn’t want to manually open a browser, write an HTML entrypoint, or anything like that. Enter phantomjs. At least it would allow me to drive tests from node thereby integrating somewhat easily with the project insofar as npm script tasks and automatic process start/stop goes. I checked its headless testing information page which pointed out a mocha integration among other things. Alas it quickly unraveled when it became clear I would have to manually manage HTML files with script tags pointing to JS bundles yatta yatta. Nope.

Next I decided to return to testem and karma both of which I have used before. I remember that testem had proven to be considerably simpler but I thought with so much time past since using either I would give each a fresh try.


  • Installed a bunch of dependencies. The Babel 6 effect all over again.

  • Configured a bunch of things

  • Discovered that console.log output did not show up in the terminal during test time

  • Discovered that console.error did but as hard-to-read unformatted string (e.g. forget logging a large complex object)

  • Discovered that the webpack integration required me to redo a webpack config (the prior one being the regular config in project root) inside the karma config.

  • Ugly and hard to read docs/website


  • poor docs

  • great console output as you’d expect (e.g. node pretty formatting)

  • was able to integrate with phantomjs without having to install another dep

  • was able to integrate with webpack without having to install another dep

  • was able to reuse my webpack configs in project root

  • generally minimal config:

  "framework": "mocha",
  "src_files": [
  "serve_files": [
  "before_tests": "webpack",
  "launch_in_dev": ["PhantomJS", "Chrome"]

Confusingly src_files above is just a watch set that triggers a run of before_tests. Based on the above points its no surprise I chose to work with testem.

Along the way I had a few more surprises:

Overall, I got a healthy does of JavaScript fatigue. Regardless, thanks to all the people that have made it even possible to do any of this.

results matching ""

    No results matching ""