Parallel test execution #6
Conversation
New "jobs" (-j) argument for specifying the number of threads to use when running tests.
|
Hello @bosonogi and thank you for your contribution! This is super useful, though I wonder if it would be better to switch to **or another Python testing framework that support If that sounds like something fun to you then go for it; otherwise I can review+merge this and move my idea to an issue for another day. |
|
Hi @mr-c Switching to an established testing framework seams like it would take significantly more effort than what was spent here. The JUnitXML schema is fairly simple, and improving how it is generated by cwltest (for eg. adding test execution times and stderr outputs) also seams like much less effort than restructuring the entire thing. Making the switch does feel like a right-thing-to-do(tm) in the long run; however as the conformance tests are data driven and those frameworks are all geared towards hand-written tests, the actual practical gains in doing so are not immediately obvious and/or significant to me at this point -- so I would rather we leave that idea for another day. |
|
While i also think that using existing testing framework makes sense, I'm not sure why wouldn't we merge this improvement, as it is already developed, and isn't big change. |
|
@StarvingMarvin I already said I was fine with merging it; feel free to press the button next time :-) |
New "jobs" (-j) argument for specifying the number of threads to use
when running tests.
concurrent.futures.ThreadPoolExecutoris used for parallel test execution, the added "futures" dependency backports this feature to Python 2.7.If a
-jcommand line argument is not specified (or is set to one), the cwltest commands behaves as it did before these changes -- with the exception that Ctrl+C needs to be pressed two times to interrupt test execution (because test execution is offloaded to separate threads).