Forum Discussion
Hi Richie
Thanks for your help, yeah with the number of test suites we have the UI actually just crashes if we try to run at the Project level 'in parallel'. We have spent a couple days trying to get max HTTP thread counts to be restricted so we only run one test suite at a time, but have been unsuccessful in applying this to testrunner.bat without everything crashing.
Might just have to leave this as unresolved or resolve as 'feature request'
Thanks for your help
Where you state "so we only run one test suite at a time"
Are you saying youre struggling to run your testsuites sequentially via testrunner? Cos thats easy to do...just ensure its not set on parallel before execution...or have i misunderstood again?
Nice one
Rich
- dm4 years agoOccasional Contributor
Apologies Richie, I mistyped there.
My settled 'ask' (and I think you're right, I need to raise this as a support ticket with Ready API) is: can we be provided a way to set:
- project to run 'Parallel'
- suites to run 'Sequential'
- but restrict how many suites are run at any one time
eg: I would like to have 60 test suites run in parallel, but only run 3 test suites simultaneouslyIt doesn't appear possible to use the HTTP maxthreadcount variable to manipulate this. If there's a way to achieve this goal, it's unclear to me.
If I wanted to restrict parallelism to 3 tests maximum at any one time, it appears my options are:
- restructure the project of ~60 test suites to be ~3 test suites with lots and lots of tests
- restructure the tests into 3 projects of 1 test suite each, and run those 3 projects in 3 testrunner.bat processes
- pay for a bigger cloud-based environment that can handle ~60 tests from ~60 test suites all kicking off simultaneously
- advise against ever running 'all the tests' and instead get testers to run sequentially for subsets of the tests, using Tags as a way of creating those subsets
This is a serious issue for our longterm usage of the Ready API product. Without a way to restrict parallelism, we basically are being asked to restructure our approach to test management, or come up with execution-time workarounds to avoid DOSing out environments.
But yeah, sounds like a support case is the better way forwards from here
Related Content
Recent Discussions
- 4 days agominhng