Parametrize more tests#6531
Conversation
|
My comment is that these changes are not just extracting parameters from tests that start with loops - they're also splitting the parts that aren't in a loop into new tests, and moving outer code into loops. They're also parametrizing not just the inputs, but the expected results as well. I don't think that every loop in a test needs to be converted into parameters. Happy to hear thoughts from others though. |
nulano
left a comment
There was a problem hiding this comment.
I think these changes look fine, and even found one test that can be improved.
My comment is that these changes are not just extracting parameters from tests that start with loops - they're also splitting the parts that aren't in a loop into new tests, and moving outer code into loops. [...] I don't think that every loop in a test needs to be converted into parameters.
While I'd agree that not every loop needs to be converted into a parametrized test, these changes look reasonable to me. There are a few tests where the tests now repeatedly load a test input image. Where this is an expensive operation, these can be converted into a fixture.
They're also parametrizing not just the inputs, but the expected results as well.
I think this is fine. I've already had a few PRs that add new tests with parametrized expected results merged here, e.g. test_imagefont:test_getlength.
An exception occurs before they would be checked.
for more information, see https://pre-commit.ci
hugovk
left a comment
There was a problem hiding this comment.
A few little whitespace/naming nits
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
No description provided.