Producing a single test bundle

[KidkArolis]

If I add preprocessors: {'**/*_test.js': ['webpack']} and I have 100s of tests, that produces 100s of large bundles - that's slow, reruns tests all the time since karma keeps detecting changes and rerunning all ests as each test bundle is produced by webpack and this sends many megabytes to the test browser to evaluate.

Instead, if I add preprocessors: {"test_index.js": ['webpack']} and require all my tests in that file (e.g. here then webpack produces 1 test bundle. However, now I have to manually maintain the full list of all my tests which doesn't scale.

I don't know enough about karma plugins or webpack yet, but do you reckon there's a way to configure webpack/karma/karma-webpack to produce ony 1 test bundle from a pattern such as **/*_test.js?

Perhaps something like dynamically, via the karma-webapck plugin, adding configuration about which modules to force include even if they're not required (is there such option?)

[sokra]

// test_index.js
var testsContext = require.context(".", true, /_test.js$/);
testsContext.keys().forEach(testsContext);

This reads all tests and require them...

[luxx]

I was running into this same issue but the solution by @sokra worked for me

karma.conf.js:

  config.set({
    ...
    files: [
      'test/helpers/**/*.{coffee,js}',
      'test/test_index.js'
    ],
    preprocessors: {
      'test/test_index.js': ['webpack']
    },

test_index.js:

// load all specs into one bundle
var testsContext = require.context(".", true, /_spec.coffee$/);
testsContext.keys().forEach(testsContext);

Personally I think it is a better default to have one bundle for all the test files. For our unit test specs, we always require the files that are needed for that spec file to execute. Because each spec has it's own bundle, modules were being evaluated multiple times, and I did not realize it for a while. Maybe update the readme to be a bit more clear? For any sizable app, misconfiguring this will make tests much slower.

[plasticine]

This is an awesome tip, I really think it might be worth mentioning this in the README.

This really saved us — we were rocking ~75MB of test code which was making testing really slow locally, and completely impossible to run remotely via something like Browserstack.

[plasticine]

I should mention that the one down-side to this technique that I’ve noticed is that it breaks watch mode for subsequently required files — only the test_index will trigger a karma rebuild.

---

Edit: I am an idiot :-)

This works perfectly...

files: [
  'test/test_helper.js',
  'test/test_index.js',
  { pattern: 'test/**/*_test.*', included: false, served: false, watched: true }
]

[KidkArolis]

I think webpack can also do the watching - just make sure karma.config.js contains webpack: {watch: true}.

[KidkArolis]

Actually, watching with webpack is better since the tests will be rerun only once - after webpack rebuilds test_index.js.
Watching with karma means that karma will run tests upon change some_test.js and after webpack rebuilds the test_index.js

[KidkArolis]

I've made a PR with updated docs at #25. Let me know what you think.

[damassi]

@plasticine, that watch update you made saved the day. Went from 10+ seconds to compile on each change down to about 500ms 👍

[plasticine]

that watch update you made saved the day.

Awesome :D

[kentor]

Hmm I tried both { pattern: 'test/**/*_test.*', included: false, served: false, watched: true } and adding watch: true to the webpack config. neither way detects a new test file for me

[damassi]

@kentor, the watch doesn't detect new files, but changes to existing files.

[jonira]

I'm having the following issue: Karma detects file changes, but executes the old version of the file. Terminating and restarting karma causes the changed version of the file to be executed.

[KidkArolis]

I had that issue yesterday..

Try upgrading karma, karma-webpack and webpack to the latest versions and
see if the issue persists. There was some breaking change somewhere
recently.

On Tue, 4 Aug 2015 11:53 jonira notifications@github.com wrote:

I'm having the following issue: karma start ends up with error: Uncaught
ReferenceError: require is not defined for my test_index.js

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[jonira]

@KidkArolis thanks for the info. After I recreated the setup and installed latest packages, Karma started working.

[wbecker]

Had the same issue, think upgrading webpack to 1.11 from 1.10.5 solved the issue. Thanks Karo!

[tomazzaman]

I may be late to the party, but I come bearing gifts :)

The solution to this problem is to not use Karma at all (for unit tests that is). Or webpack for that matter.

Here's the gist we use to run tests directly with Mocha: https://gist.github.com/tomazzaman/1e2c71e1afb6a45c1001

Save the file as mocha-runner.js and run it with $ babel-node mocha-runner.js

The gist is pretty well documented, so you shouldn't have any major problems understanding it.

[martijnarts]

I'm having the following issue: Karma detects file changes, but executes the old version of the file. Terminating and restarting karma causes the changed version of the file to be executed.

@jonira did you ever find a solution for this issue?

[robinelvin]

I have the same issue as @jonira had (and probably @TotempaaltJ too) in that changed files trigger the tests to reload but it executes the old code. I should add that my tests are written in Typescript and I don't see any output which tells me they are recompiled.

I'm using a test_index.js which pulls in all the .ts files as recommended.

Versions:
karma 1.3.0
karma-webpack 1.8.0
webpack 1.13.3

[luchillo17]

@robinelvin Same here, i have karma-webpack configured and it indeed doesn't recompile the tests.

Also saving the karma config triggers the reload, but doesn't update the configs (that makes a bit of sense since it is a config file, but the above doesn't).

Versions:
karma 1.4.1
karma-webpack 2.0.2
webpack 2.2.0