3

I am trying to set up automated unit tests for my JavaScript code using PhantomJS and QUnit, and also to generate code coverage with JSCover - basically as described here: http://julianhigman.com/blog/2013/07/23/testing-javascript-with-qunit-phantomjs-and-jscover/

The thing is that this page, and others I have seen on the subject, assume you only have a single HTML page that will load and run all of the QUnit tests in your project.

In my case I have something like 50 JavaScript source files, and a corresponding .js unit test file for each. I was going to go down the route of having a separate HTML page per unit test file, so that during development I could run tests for a specific file in-browser individually. But apart from the overhead of having to maintain 50 (admittedly very basic) HTML files, I am not sure how to make this work nicely with JSCover (without generating 50 coverage reports).

Is it best practice for me to just include all of the 50 unit test files into a single HTML page?

Michael Bednarek
  • 169
  • 1
  • 13

1 Answers1

2

I would choose to include all 50 unit test files in a single HTML page.

You can use QUnit modules to break up your tests into groups if you don't want to run all of the tests all of the time. You can then run tests one module at a time by using the drop-down list at the top-right of the QUnit page or by using a query-string parameter in the URL, for example http://localhost:8000/qunit-tests.html?module=SomeModuleName or file:///path/to/your/qunit-tests.html?module=SomeModuleName.

Including all 50 test files in the same HTML page means you can run all of the tests in one go and then generate code coverage for all your code. I also can't help but feel that running PhantomJS on 50 HTML pages one after the other would be considerably slower than running it on one single larger HTML page.

Luke Woodward
  • 63,336
  • 16
  • 89
  • 104
  • 1
    Good point about just using the QUnit GUI/query string params to limit to the tests you're interested in. I think I'm making the problem harder than it needs to be :-) – Michael Bednarek May 30 '14 at 09:47