Remove non deterministic test param

[holmanb]

Remove non-deterministic test parameter
    
Non-deterministic test parameters have multiple downsides:
 - potentially non-deterministic tests results
 - breaks parallel test execution via xdist.

Additional Context

There are other things in our unittests that cause intermittent failures during parallel test execution, but this one will cause failures every time. The random input here is frankly unnecessary. With this change I can (usually) run pytest tests/unittests -n2 locally in ~25 seconds, rather than the normal >40s to complete.

[TheRealFalcon]

In this specific instance I agree that the randomness doesn't really add much, but in general I think "any value of this type" should be considered valid input for a test. The failure is because parametrized test names are auto-generated based on the parameters.

This can also be fixed with pytest.param(CiTestCase.random_string(), None, id="random_string"),. In this case I'm fine with either one, but in general, I think I'd prefer we keep random parameters and assign ids to parameters.

With this change I can (usually) run pytest tests/unittests -n2 locally in ~25 seconds, rather than the normal >40s to complete.

Lucky...mine are double that 😄

[TheRealFalcon]

Let me know which you prefer for this test.

[holmanb]

In this specific instance I agree that the randomness doesn't really add much, but in general I think "any value of this type" should be considered valid input for a test. The failure is because parametrized test names are auto-generated based on the parameters.

This can also be fixed with pytest.param(CiTestCase.random_string(), None, id="random_string"),. In this case I'm fine with either one, but in general, I think I'd prefer we keep random parameters and assign ids to parameters.

Good info, thanks! I'll update the PR to set the parameterized test name.

[holmanb]

@TheRealFalcon looks like param doesn't exist on some of the versions of pytest that we use. I don't see reference to a change in the api in the docs, however. Unless there are any objections to this iteration I'm fine with this approach.