We already use pytest, but still derive our test classes from traditional unittest.
This is perfectly valid, but we cannot use some nice pytest features that way. As an example, pytest has built-in support for capturing stdout/stderr, so we could drop our own implementation. I also like pytest's more intuitive assert syntax.
Concrete reason why I ask is that I recently extended our own capture_stdout implementation to support an arbitrary number of arguments and now I noticed that with our own implemenation, I can't capture stdout and check the return value at the same time. All of that would already be available from pytest.
It would however mean a larger rework, but I think it would be possible to migrate file by file where needed.
If you're interested, @tngraf, I could try adding my new tests for #33 in pytest-style or also rewrite the "project createbom" tests in #37 to pytest style.
We already use pytest, but still derive our test classes from traditional unittest.
This is perfectly valid, but we cannot use some nice pytest features that way. As an example, pytest has built-in support for capturing stdout/stderr, so we could drop our own implementation. I also like pytest's more intuitive assert syntax.
Concrete reason why I ask is that I recently extended our own capture_stdout implementation to support an arbitrary number of arguments and now I noticed that with our own implemenation, I can't capture stdout and check the return value at the same time. All of that would already be available from pytest.
It would however mean a larger rework, but I think it would be possible to migrate file by file where needed.
If you're interested, @tngraf, I could try adding my new tests for #33 in pytest-style or also rewrite the "project createbom" tests in #37 to pytest style.