Closed arihan closed 2 years ago
Please provide a project to fully demonstrate this issue with clear comparable timings
I'm unable to handle anything without knowing the full issue (number of tests, how resource heavy each test is, number of threads, the amount of memory allocated to the JVM and build process etc..)
If you find that using the Cucumber CLI is faster in your project, it may be beneficial to use that instead of Courgette.
Some further info on how Courgette works:
Courgette uses a queuing system and creates a queue of tests based on the number of threads (or an optimised thread count that Courgette determines at runtime)
Courgette then dequeues tests in batches and waits for all tests in each batch to complete before the next batch can start. This is the way this library is designed to work.
I've not had anyone report any issues where Courgette runs in double the time so if you can provide a project to demonstrate double timings, that would be great!
Also worth mentioning, Courgette does additional processing at the end of each test run for merging multiple reports into a consolidated report and depending on the Courgette plugins you use this could slightly increase the timings due to additional post test execution processing.
When we use the
cucumber.api.cli.Main
for a multithread run then the thread finish the scenario picks the next scenario immediately. However while using this library then say starting with parallel run with thread count -10 then until all the threads finished the next set of 10 scenarios don't start. As example :- at the beginning 10 threads started 10 scenarios. Once all the threads finished their respective scenario then next set of 10 scenarios would start .We observed it's almost made the execution time to double. Is there any plan to handle this ?
My comment might be totally unrelated but I was getting a lot of OutOfMemory issues after running a test suite using 4 threads after around 2 hours of running. This started occurring after a cucumber update. In my case, the gradle worker needed more memory as it was running out of memory when trying to store the test results and it was increasing the test run times by a lot
I've set the gradle worker processes for the test task to include the following, which fixed my issue. Give it a try and see if it makes any difference
test {
// heap settings for the Gradle worker processes
minHeapSize = '256m'
maxHeapSize = '2048m'
}
Closing inactive issue.
When we use the
cucumber.api.cli.Main
for a multithread run then the thread finish the scenario picks the next scenario immediately. However while using this library then say starting with parallel run with thread count -10 then until all the threads finished the next set of 10 scenarios don't start. As example :- at the beginning 10 threads started 10 scenarios. Once all the threads finished their respective scenario then next set of 10 scenarios would start .We observed it's almost made the execution time to double. Is there any plan to handle this ?