Not convinced about that mixedDurationTest. I'm absolutely good having a "short" and "long" target, because it's useful during development to be able to run some sanity check before committing, but the long test needs to be run by jenkins or the like sooner or later, so I'm not sure what running a random set of tests really solve.

We want to implement "duration tests" before the next release and the current test will be a foundation for these types of tests.

Ideally, the duration tests will run for at least 72 hours and ensure that the driver continues correctly, without fail. I'm -1 about having these 72 hour tests grouped up with the "long tests" since there is no need for Jenkins to run these on each build.

Ideally, the short tests are for sanity checks, the long tests are for Jenkins, and the duration tests will be run before each major release.

For the record, I'm still not convinced by mixedDurationTest.

+1 on not being entirely convinced. I would ideally increase the number within the for loop to run longer multiple day tests and get rid of the cluster discarding prior to an official test.

For now that runs for a "small duration", if you will, but we can hit the ground running to adapt the test when needed.