ng test specific file

[kirjai]

Is it possible to specify a path to a specific file when running ng test? Or only run tests in specific files somehow? Can't seem to find any issues or documentation about it anywhere.

Thanks!

OS

Mac OSX (El Capitan)

Versions

angular-cli: 1.0.0-beta.18
node: 4.4.2
os: darwin x64

[Meligy]

Been having this problem this week too.

My workaround was to go to src/test.ts, and modify line 30:

  .then(() => require.context('./', true, /\.spec\.ts/))

to match only the tests I'm interested in.

This remains only a workaround though. I don't think this is good enough to be the official thing.

[filipesilva]

Hm, isn't it enough to just use fit instead of it on a test? e.g. fit('should create the app', async(() => { (...)

[kirjai]

Ah, great! Didn't know about fit, which totally works, thank you very much!

[lygstate]

How to use fit?

[Meligy]

You know how your tests are usually like:

describe('Something', () => {
  beforeEach(() => {
    // ... preparation
  });

  it('should ...', async(() => {
    // ... test 1 logic here
  }));

  // ... more tests and/or nested `describe()` calls
});

If you replace the it() call of one or more tests with fit(), only these tests will be run.

You can do the same with describe() as well. If you replace it with fdescribe() (prepending f to it), only the tests in this fdescribe() call (and any other fit() tests outside it) will be run.

[lygstate]

does this support for mocha?

[jasdeepkhalsa]

The usage of fit() or fdescribe() is really a workaround I believe and this functionality should be supported in ng test

In fact, I think a lot of the CLI from Facebook's Jest (http://facebook.github.io/jest/docs/en/cli.html#content) could be borrowed for example:

• ng test --watch - To watch and re-run only the tests which have changed
• ng test --coverage - Free code coverage report
• Snapshot testing in general

[Meligy]

Most of these are Karma / Jasmine issues rather than CLI issues.

At the moment the CLI is committed to only supporting one test tooling chain, which is Karma and Jasmine. Since there cannot be hidden 100% like a bundler is (because you use the test framework APIs in your tests), the choice is also exposed to the users. This has nice side effects like:

• You can easily add / replace karma reports in karma config
• You have full control over the test.ts file used to run the tests

Also, if you agree to give up calling ng test (replacing it with a test npm script for example, so you just run npm test), you can easily move away to Jest if you prefer to. I have tried it myself in a medium size real project and found it pretty easy.

It's worth mentioning that the built in jasmine HTML reporter does allow you to click on a single test or suite of tests and only have these run, and the CLI itself supports a watch mode (enabled by default actually, and can be changed either per CLI call, or by changing the default in Karma config). It's not a Jest-style watch for changed files only, but that's because it's simply not Jest. It's Karma + Jasmine.

[Meligy]

What might be useful though is a lint rule that would fail linting if you have fdescribe / fit (similar to how some lint rules fail calling console). Not sure if it's reasonable to include in the CLI template, because it's yet another weird package in the project's devDependencies. But it's also easy to add manually in your project anyway.

[dasAnderl]

a feature passing the spec name or a regex pattern like jest has it, would indeed by nice. i know about fit and xit, however its not optimal. you have to replace all its in the spec and even more important you might forget to unfit before commiting.

[Meligy]

As far as I know, this is inherent in Karma itself. And / or Jasmine and / or karma-webpack.

It doesn't have an incremental run like jest, so the name pattern thing doesn't work as well.

If there is some reporter or plugin that can do it, you can add it to the Karma config yourself.

Also, if you really want to, you can use Jest with your Angular CLI project using https://github.com/thymikee/jest-preset-angular -- although no particular official support for it. ng test might not work - not sure, but spec files should be compatible with Jest as it's very close to Jasmine.

[dasAnderl]

i tried jest preset angular. it works somehow but not really well for me. i have some tests failing, which dont fail with ng test. for now i stick with fit and ng test, since i was able to speed up the test suite significantly using beforeAll for initialization of the testbed instead of beforeEach (thx to @vvasabi angular/angular#12409 (comment)).
this approach yields currently the best results for me. however the watch/pattern/mode jest offers seems superior and would be great to have in angular "natively" if somehow possible.

[Meligy]

It seems that Jest is really great for you. I tried it a few months back on a medium project (200+ tests) and went fairly well after following

• The "Migration from Jasmine" part from the present post -- Mainly custom failure messages were not supported, and I needed to change a few jasmine to jest or expect
• The "Troubleshooting" section of the readme -- Especially the transformIgnorePatterns part

It worked well. The only reason I couldn't keep it was that the team I worked with was comfortable with current tooling and not ready for a change at the time, especially tha the tooling was standard across multiple teams.

It's beyond the scope of this issue and Angular CLI with Angular's current official preferred tooling. But I thought it might be useful to mention.

Also (and still out of scope), beforeAll can have unexpected side effects between tests. I wouldn't really recommend it. Instead, ensuring you add too little to TestBed testing module seemed to help a few teams on multiple projects, which you can achieve by mocking everything other than the test subject. You might even be able to test some things with direct instantiation
new WhatIWantToTest(mockDependency1).

But again, as it stands today, it's not very relevant here anyway.

Thanks for sharing the comment link still BTW.

Cheers,