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.

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.

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.

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.

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

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.

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.