5 ms·
Agreed. One of the most confusing libraries with a ton of magic going on behind the scenes. I also detest PyTest, although not a std lib, pytest is one of the w
by systemvoltage 4y ago
Agreed. One of the most confusing libraries with a ton of magic going on behind the scenes. I also detest PyTest, although not a std lib, pytest is one of the worst in terms of explicitness. It’s very useful but that’s orthogonal. I’ve seen newcomers to python struggle to grasp how pytest just manipulates a billion things behind the scenes.
Overall, I prefer less magic and more explicitness.
- oefrha 4y agoPSL unittest is very explicit and has no magic. Ironically it also has Java written all over it. You must be the first person I met who prefer unittest to pytest.
- txru 4y agoI sometimes prefer unittest too! Pytest is very opinionated about how and when it's going to be run. If you want to put a test in say, Jupyter or a Markdown block, unittest is much more amenable to just doing what you want without having to read through documentation to break a whole bunch of magic behavior.
- dragonwriter 4y ago> PSL unittest is very explicit and has no magic. Ironically it also has Java written all over it. By “Java written all over it” do you mean that like JUnit for Java, it's an implementation of the xUnit pattern derived from SUnit for Smalltalk?
- oefrha 4y agoIt didn't have to copy everything down to the camelCase if it was just an implementation of the xUnit pattern with no Java influence.
- dragonwriter 4y agocamelCase is idiomatic in Smalltalk, which as a language and a community was a pretty big influence on other dynamic OO languages like Python and Ruby, and from whence SUnit comes, and thus the whole xUnit world, derives. So, it's maybe not the best evidence that the Python version is particularly a clone of the Java port.
- deleted 4y ago[deleted]
- simonw 4y agoDisagree on pytest: it's the first testing framework I've used in ANY language which has genuinely made me enjoy writing tests. It has a bit of an initial learning curve, but once you understand how fixtures work it's amazing how productive you can be with it.
- deleted 4y ago[deleted]
- miohtama 4y agoThe implicit magic makes writing pytest tests painless. Also with improvement of type hinting, tooling like PyCharm starts to understand pytest better and make it easier to read and manage and a lot of the magic can be dispellt by written out explicitly. Though this need some discipline from the dev team.
- mtlguitarist 4y agoI wish I could agree. Every aspect of pytest that I like (fixtures, plugins, etc.) is marred by a boneheaded move to make them autoloaded by default. Loading should be explicit/opt-in. It's dumv that if you pip install something that adds a new pytest plugin it'll automatically modify your runtime behavior. Some of the plugins are great (shoutout to pytest-socket), but it has the same issue flake8 has with the plugin ecosystem where the quality varies wildly. I might be in the minority but I also find python's mock implementation awful. Mockito in Java is way better where you explicitly state which calls you expect and if you get an unexpected call it errors out.
- codethief 4y agoStrong agree on all points! The number of times I had to debug into the pytest source code because developers (the ones using pytest) thought it would be cool to use some decorator black magic to manipulate global state behind the scenes which pytest not just makes very easy but actually encourages and which was obviously going to break sooner or later… And regarding the sibling comment: Yes, I prefer unittest as well.
- bornfreddy 4y agoWhat do you mean? Pytest rules! Yes there is some magic, but if you let it take control, it is very convenient to write and run tests with it. Just... you need to trust it and it will do its job.
- systemvoltage 4y agoI use pytest all the time. Doesn't mean it is well thought out. It could have been so much better with more visibility and control, and less magic.