I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.
Most basic functions are imported from a shared module (rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amount
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
Depends on the project of course, but you can absolutely write integration tests with pytest. In my experience, it’s easy to @pytest.mark.integration the integration tests, then pass -m to the CLI to filter between integration and non-integration tests. You can load the environment-specific stuff in fixtures that are only used by those tests as well, and do setup/teardown with fixtures of course as needed.
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.
Most basic functions are imported from a shared module (
rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amountDepends on the project of course, but you can absolutely write integration tests with pytest. In my experience, it’s easy to
@pytest.mark.integrationthe integration tests, then pass-mto the CLI to filter between integration and non-integration tests. You can load the environment-specific stuff in fixtures that are only used by those tests as well, and do setup/teardown with fixtures of course as needed.