elyezer
commented
7 years ago As for the second case, the unittest test runner from the standard lib doesn't provide any facilities for parallelization. Maybe it can be done with unittest, but I'm unclear on how. We might need to whip up something interesting with a library like testtools, or we might need to pick a different test runner.
I think we should consider picking py.test. It provide some interesting features other than being able to run in parallel (on a single or multiple machines as well as single and multiple python processes). Features like py.test fixtures may help on ensuring the system state for those tests.
I will leave another option which could be having multiple Pulp servers using libvirt or docker so we could make each test in parallel act on its own Pulp server and then some reset function may become irrelevant on this setup.
Pulp Smash takes a while to execute, and it'd be nice if we could reduce the running time. One way to accomplish this is to parallelize tests. If parallel tests are desired, then two problems need to be resolved:
As for the first question, it's good to realize that many test cases perform global actions. For example, a test case might:
reset_pulp().)reset_squid()and theServiceManagerclass.)Any test case which is to be run in parallel must either be refactored to not do these things or must be marked as requiring serial execution.
As for the second case, the unittest test runner from the standard lib doesn't provide any facilities for parallelization. Maybe it can be done with unittest, but I'm unclear on how. We might need to whip up something interesting with a library like testtools, or we might need to pick a different test runner.