263
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Jun 2026
263 points (96.8% liked)
Programming
27173 readers
354 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
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.