Jest: ddescribe and iit do not work

[binarykitchen]

Somehow I cannot pick one test only anymore. Jest always scans for all tests and runs them all. Adding one ddescribe() in one of them has no impact.

[jeffmo]

I think you're looking for it.only() and describe.only()?

[binarykitchen]

Yes, I tried these too. No effect. Probably broken?

Beware that I am running the tests through gulp-jest ...

[jeffmo]

Hmm, it works for me on master...what version are you using?
Just to be completely clear about what I'm seeing work for me:

describe('suite', function() {
  it.only('a', function() { console.log('a'); });
  it('b', function() { console.log('b'); });
});

(I only see 'a' printed with the above test)

[binarykitchen]

Yes, that's what I am after and is not working here.

gulp-jest is using jest-cli version 0.4.0, see
https://github.com/Dakuan/gulp-jest/blob/master/package.json#L24

Can you try the above example of yours within gulp-jest?

[emmenko]

My 2 cents: afaics it.only works, but in the related describe block (meaning if you have many test files they still run). What I would expect instead is that from all the test files, only the one marked as it.only is run.

PS: the repo looks quite dead (over 2 years ago) https://github.com/davemo/jasmine-only

[jeffmo]

Given that test files run in parallel, I don't think it'd be possible to know to skip other test files until it's too late. What you can do (and what I do often) is specify a unique part of the name of a test file as the first arg to the test runner. This will enure only tests matching that arg string get executed (and then internally, only the .only() test will run)

[emmenko]

The classic workaround ;)

[emmenko]

PS: the new jasmine syntax to run specific specs is to "focus" them with fit, fdescribe
http://jasmine.github.io/2.1/focused_specs.html

Not sure if it's possible to integrate it in jest though, not at least before upgrading to v2.0...
Refs https://github.com/facebook/jest/issues/74

[binarykitchen]

@jeffmo sure, we all could do your classic workaround but let's think of DX and try to make our lives easier. I'd welcome a fit and fdescribe integration into jest. Really.

[jeffmo]

@binarykitchen: I don't think fit or fdescribe solve the problem here...and I don't see a solution, do you? How do you deal with the fact that tests run in parallel and therefore you can't know until you've already run all the tests whether one of them is marked as "focused" or "only"?

[binarykitchen]

good point @jeffmo i am sure this problem has already been solved somewhere else with other unit test runners such as mocha. load and parse all files first and then decide which tests to run.

[emmenko]

The karma runner for jasmine supports that. I don't know how it works exactly and how it differs from jest, still I think it's worth mentioning...

https://github.com/karma-runner/karma-jasmine

[zeroliu]

Any updates on supporting fit & fdescribe in jest?

[cpojer]

Given that jest runs tests in parallel this seems quite impossible as @jeffmo pointed out earlier. What I've found to work well is it.only and passing the name of the test to jest, so it only runs a single file:

it.only(...) and jest MyTest.js

[danielstern]

+1
By the way this seems quite possible, just the user would need to specify not to run the tests in parallel.

[cpojer]

@danielstern you can now use -i -t <pattern> I guess.

[arcseldon]

For Node.js testing, just moved over to try Jest as opposed to my former go-to test dependencies (Mocha, Chai, Proxyquire and Sinon) - the idea of consolidating to just having to use Jest was a primary motiviation, together with Mock by default behaviour... really liked the idea of cutting down on the test harness plumbing. So far the experience using Jest has been really disappointing for reasons (one of many) such as this - too many workarounds and sub-optimal hacks to get equivalent behaviour that is expected to be out of the box. In fact, using Jest has resulted in more plumbing, not less - and less options / power. Using Mocha, Chai, Proxyquire and Sinon is not ideal either (hence the Jest trial). Shame that a lot of the promise for Jest has not (yet) been realised - frustratingly close to what I was looking for - shall take another look in 6-12 months as I still think the library may one day get there.

[thymikee]

@arcseldon what has disappointed you about Jest? Can you elaborate on that? It's crucial to get such feedback, so we can work on this to make Jest better.

[cpojer]

@arcseldon this is a very vague comment on a random issue and isn't very helpful. If you have concerns or concrete issues and would like to see Jest improved, please help us by starting discussions in the appropriate places or send us pull requests to make Jest work for you.

[unional]

I think it is possible. ava also runs tests in parallel and its test.only() is working as expected (only those tests are ran across all test files)

[chriswatrous]

Here's a workaround I'm using, in package.json:

"test:unit:only": "jest $(grep -rl '\\.only' test/unit)"

then

npm run test:unit:only

[SimenB]

FWIW ava has an issue for --only flag now. Maybe we should have the same?

https://github.com/avajs/ava/issues/1472

[Diokuz]

So, the main problem here is parallel execution, right?
What about --runInBand then? Can we fix the problem at least for non-parallel runInBand mode?