Hacker News Reader

Comment by systemvoltage | Hacker News Reader

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.

View on HN

Disagree 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.

The 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.

I 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.

PSL 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.

I 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.

> 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?

It didn't have to copy everything down to the camelCase if it was just an implementation of the xUnit pattern with no Java influence.

camelCase 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.

What 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.

I 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.

Strong 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.

Reply on news.ycombinator.com