Run A Single Unit Test

[jongunter]

OS?

Windows 8, Mac OSX El Capitan

Versions.

angular-cli: 1.0.0-beta.19-3
node: 6.3.0
os: win32 x64

Mention any other details that might be useful.

This is a feature request. The ability to run a single .spec.ts file would be excellent, when you guys get the chance. I recently switched from using Angular1 in Visual Studio where one could use the Test Explorer or the Chutzpah extension to run a test on a single component. Working on a large enterprise application, it's a huge pain to run the entire unit test suite (which takes a few minutes) every time I refactor a single component (and thus only need to run that component's tests).

[lordmat0]

You should be able to do fdescribe or fit instead of describe or it with Jasmine which forces a test.

There is also xdescribe and xit which skips tests

[mattdistefano]

Dup of #3436?

[zsfarkas]

You can temporarily change the following line in the test.ts file, to restrict the test-suite to one particular test-specification:

...
// Then we find all the tests.
let context = require.context('./', true, /\.spec\.ts/);
...

For example, if you want to run only the test-file hello-world.spec.ts, just change the file, like this:

...
// Then we find all the tests.
let context = require.context('./', true, /hello-world\.spec\.ts/);
...

Before push, you should run all the test-cases, so you can remove the changes of test.ts.

[mattdistefano]

@zsfarkas Yeah, I'm aware of that option. I'd prefer something that doesn't require editing any of the source files, though. In our webpack-based build, we did this by passing a command-line param w/ the folder path into the ContextReplacementPlugin, but we don't have access to the webpack config in the CLI, and I don't know of a way to get a command line arg into test.ts.

[zsfarkas]

@mattdistefano Ok, that would be a dream ;-)

[jongunter]

While the solution of changing code to make a single test run technically works, it's really not feasible when you have an application with hundreds of components. TDD only works well if you can have fast, frictionless cycle of test/code/test/code/test/code. Running the entire app's suites, x-ing out suites, or changing karma config, every time a single component is changed, makes that cycle very slow.

[filipesilva]

Ok so we have fdescribe and friends, plus chaging test.ts. Those are two options that exist right now.

@mattdistefano mentioned the grep option in #3436, but I can't find any documentation. Can you refer me to it?

I'm not aware of any facility to only run tests related to the file that changed however. I don't think karma supports such a thing. It's not as simple as running name.spec.ts when name.ts changes, since tests might use use classes from other files.

[mattdistefano]

@filipesilva Sorry about the late reply - I think it's actually only available in the mocha plugin, not karma itself.

[EugeneSnihovsky]

I'm new in angular-cli, so my solution can be not perfect, but it's work (tested in angular v.4.2.4 application created with angular CLI v.1.1.3 on os X and ubuntu).

1. install minimist library to parse argument options from bash

npm install --save-dev minimist

2. modify package.json file scripts section test field to
   "test": "ng test --watch=false --code-coverage --tags $tags"

NOTE: --watch=false --code-coverage need to me for code coverage. If you don't use this feature, you can simplify it to

"test": "ng test --tags $tags"

3. Modify karma.conf.js. At top of file add

const argv = require('minimist')(process.argv.slice(2)),
  tags = (argv.tags !== true) && argv.tags;

and in config object in client field (that is also object) add field args

client: {
      args: [tags],
      clearContext: false // leave Jasmine Spec Runner output visible in browser
    }

4. Modify logic in src/test.ts. After

declare const __karma__: any;
declare const require: any;

add

const tags = __karma__.config.args[0];

and change

// then we find all the tests.
const context = require.context('./', true, /\.spec\.ts$/);
// and load the modules.
context.keys().map(context);
// finally, start Karma to run the tests.
__karma__.start();

to

// then we find all the tests.
const filterRegExp = (tags) ? new RegExp(tags, 'g') : /\.spec\.ts$/,
    context = require.context('./', true, /\.spec\.ts$/),
    specFiles = context.keys().filter(path => filterRegExp.test(path));
// and load the modules.
specFiles.map(context);
// finally, start Karma to run the tests.
__karma__.start();

That's all. Now to launch all unit tests

npm test

to launch just tests that located in footer.component.spec.ts file

npm test footer.component

[rjcorwin]

Changing a test definition's it(.. to fit(... will cause only those tests marked as fit to run. If you want to run a specific file's tests, do a find and replace in that file to change it( to fit(. This is working great for me in my test driven development process.

[alexluecke]

@EugeneSnihovsky that works, however, it seems (at least in my case) webpack is still building the entire project. As such, there's no reason to use this over using fdescribe or fit since it does not offer any performance advantage. In fact, sans watching the build, it's slower since it needs to rebuild each time. I think the end goal should be to not build the entire project in order to run a single test.