are there any feature to support parallel run at scenario level?

[hemanta8841]

Are there any feature to support parallel run at scenario level?
Currently cucumberjs has the support to run parallel <NUMBER_OF_SLAVES>
this will run parallel at scenario level.
If there are no feature available for jest-cucumber as of now, is there any plan in near future to add this one ? Appreciate your response

[bencompton]

Scenarios end up being Jest tests, and Jest already runs tests in parallel by default unless runInBand is used.

[hemanta8841]

@bencompton let me specific what I am asking : is test.concurrent is supported in jest-cucumber ?

[bencompton]

Okay, I see what you're asking now. I have actually never used test.concurrent. Looks like Jest executes test suites in parallel by default, and test.concurrent forces parallel execution per scenario.

test.concurrent is not supported at the moment, but it would be worth adding support for the other aliases, like test.only, test.skip as well.

[bencompton]

It was a quick change, so I went ahead and implemented test.only, test.skip, and test.concurrent and published a beta package to NPM v2.0.7.

[hemanta8841]

ok, Fantastic , so quick , appreciate .

[sibyldawn]

Hi I would love any documentation to explain how to use test.concurrent in the jest-cucumber context.

[sibyldawn]

Regular Test

Used Test.Concurrent

This is the current behavior when I use test.concurrent. Compared to the regular test the run time is the similar.

[MetaMmodern]

Hey, Heey) One year passed) Is there any progress with this?

[bencompton]

This is working as expected as far as I know, and ends up running your scenarios with Jest's test.concurrent API. That being said, the Jest docs say that test.concurrent is still considered experimental. In addition, I would add that there are a lot of variables with parallelization in general, and depending on a number of factors, performance gains may not be as linear as one might expect. Jest already runs test suites (i.e., tests from different files) in parallel, and test.concurrent just allows specific tests within single suites to run in parallel as well.

Since test.concurrent is still experimental in Jest, it is likewise still experimental in Jest Cucumber. It may be worth playing around with it to see if you can improve your test runtimes, but YMMV, and I would also suggest having a look at the known issues.

It's probably worth adding this info to the docs at this point and then closing this issue.

[MetaMmodern]

This is working as expected as far as I know, and ends up running your scenarios with Jest's test.concurrent API. That being said, the Jest docs say that test.concurrent is still considered experimental. In addition, I would add that there are a lot of variables with parallelization in general, and depending on a number of factors, performance gains may not be as linear as one might expect. Jest already runs test suites (i.e., tests from different files) in parallel, and test.concurrent just allows specific tests within single suites to run in parallel as well.

Since test.concurrent is still experimental in Jest, it is likewise still experimental in Jest Cucumber. It may be worth playing around with it to see if you can improve your test runtimes, but YMMV, and I would also suggest having a look at the known issues.

It's probably worth adding this info to the docs at this point and then closing this issue.

Hello there and thanks for fast response. As far as I know jest runs only suites in parrallel, and with that said there is another fact. Only files are considered as suites by Jest. By writing "describe" you cannot achieve the same result, as with seperate files, it just doesn't work and Jest team still did not fix their documentation about it. So it is almost untrue for this project that tests run in parrallel. Except you made an extraordinary tweak iside your code to make jest think, that blocks of code are suites. But I'm browsing the source and can't find it. What do you think about that?

[bencompton]

So it is almost untrue for this project that tests run in parrallel. Except you made an extraordinary tweak iside your code to make jest think, that blocks of code are suites. But I'm browsing the source and can't find it. What do you think about that?

Outside of autoBindSteps, each step definition file is matched separately by Jest and is seen as a separate test suite, which can be verified by running the examples and noting that there is more than one test suite. However, in the case of autoBindSteps where there is a single file being matched by Jest that binds all steps, then it would indeed be a single suite. There is currently no magic going on in Jest Cucumber to add parallelism in this case. One way to work around that at the moment would be to have multiple files matched by Jest that run autoBindSteps on a subset of feature files, which should then create multiple test suites. test.concurrent may also be more effective in this case as well since there is not already parallelism from multiple test suites.

I would be curious if there is something in the Jest API outside of describe blocks to allow more manual definition of test suites that autoBindSteps could leverage, or perhaps there is some sort of improvement that could be made to autoBindSteps itself such that each feature file ends up as a separate test suite.

[MetaMmodern]

'each feature file is as a seperate test suite'. This is definitely the thing that I'm trying to implement.

[bencompton]

'each feature file is as a seperate test suite'. This is definitely the thing that I'm trying to implement.

That may or may not be possible, but one easy solution would be to have a flag in autoBindSteps that makes it use test.concurrent instead of test. This would still be considered experimental, but experimental would be better than nothing I suppose.

[siva-natarajan]

@bencompton - raised this PR #147 to implement a flag for concurrent execution