5 ms·

I have a personal gripe against Pytest. It extremely implicit, does so many things behind the scenes that it makes learning the library difficult for new comers

I have a personal gripe against Pytest. It extremely implicit, does so many things behind the scenes that it makes learning the library difficult for new comers. I had a hard time. For example, fixtures are passed as arguments in function. You can't use IDE tools to find out where they are passed from. There are dozens of things that go completely against the philosophy of Python: Explicit is better than implicit. Pytest is full of magic, it irritates me. The kind of questions asked on Stack Overflow reflects my personal experience with libraries of this kind. So many people are confused.

epgui 4y ago
I agree with you completely, but... > There are dozens of things that go completely against the philosophy of Python: Explicit is better than implicit. I have found that this is not just true of pytest, but also of the python language! :P
- uranusjr 4y ago
  It is the _Zen_ of Python. Words are naturally elusive, contradiction is harmony.
  - epgui 4y ago
    When coming back from a lisp like Clojure, it feels a bit more like a cacophony, but I agree with you in general haha.
- Aperocky 4y ago
  > I have found that this is not just true of pytest, but also of the python language! :P Curious as to how? It is pretty explicit and simple when compared against the pack.
  - epgui 4y ago
    It depends what's in the pack of comparables... But once you get used to an actually simple language like Clojure or Haskell (neither of which is perfect, but both of which are very very simple) it really is hard to unsee all the accidental complexity of most languages.
Aperocky 4y ago
I have the exact opposite experience, writing tests are actually sort of enjoyable using pytest. The trick might be not using an IDE at all, I consider python and most of its frameworks explicit enough to write with editors like vim. I never found a need to use an IDE for python even when the projects gets larger, because even then the unix tools seemed to work much better at whatever that IDE is doing. This compares sharply against languages in the JVM family.
- progval 4y ago
  with or without IDEs, you cannot easily tell where fixtures come from. Is it from the same module? same package? a plugin? pytest itself? some non-test module that happened to be imported? You can't tell. And it's a global namespace where everything can override everything else.
  - Aperocky 4y ago
    The hierarchy is pretty clearly stated here and it seemed to be against what you're suggesting: https://docs.pytest.org/en/6.2.x/fixture.html#fixture-availability https://docs.pytest.org/en/6.2.x/fixture.html#fixture-availa..., even though I don't think the hierarchy matters much if the fixtures are explicitly placed and named. If you're instantiating the same fixture name across a bunch of different tests, using similar fixtures in different locations and not use import or a central or hierarchical location to define your fixtures after you have accumulated a number of similar items, I find it hard to blame the module for not being explicit.
    - progval 4y ago
      If for some reason a fixture is misbehaving, it's hard to find what package provides it because I don't explicitly import it. I have to use `pytest --fixtures | less` and search for the fixture's name (or `pytest --fixtures | grep -C 50`) > If you're instantiating the same fixture name across a bunch of different tests It means I cannot name my fixture `database`, I have to call it `myplugin_database` instead to make sure it won't conflict with other plugins. And tests using this fixture have the long `myplugin_database` as argument. Python already had namespaces as first-class citizens, it's a shame we have to go back to name prefixes.
sintezcs 4y ago
I am using PyCharm and it perfectly integrates with pytest fixtures. You can navigate to the fixture definition with a click, and it clearly distinguishes fixtures and common arguments.
- mrelectric 4y ago
  Also works in VSCode with little setup
  - maroonblazer 4y ago
    "with little setup" could be construed as "very little" or as the opposite; i.e., some amount of non-trivial setup. Which meaning did you intend?
  - kkirsche 4y ago
    The following link describes the set up used / needed by VS Code to integrate the framework with the IDE: https://code.visualstudio.com/docs/python/testing https://code.visualstudio.com/docs/python/testing
eirki 4y ago
I absolutely agree about fixtures-as-arguments thing. Ward does this a lot better, using default values for the fixture factory. There's a long issue on ideas to implement something like that as a pytest plugin (https://github.com/pytest-dev/pytest/issues/3834 https://github.com/pytest-dev/pytest/issues/3834), but it seems the resulting plugin relies on something of a hack.
liendolucas 4y ago
Same feelings here. When I see pytest is like: "oh no...". Been using nose2/unittest for ages and I will continue to do so because is so damn simple. > that it makes learning the library difficult for new comers Not only for newcomers, I've used in the past and if I need to pick it up again I believe I'm going to spend some time refreshing a ton of things and probably get got caught by some caveat. > fixtures are passed as arguments in function Exactly questioned that myself so long ago. Implementing fixture functionality from scratch in Python (even supporting different formats) is only a few lines of code.
packetlost 4y ago
Hard disagree. Pytest is a great. Even with a really basic language support in neovim I have no trouble using it. For newcomers, it does have a learning curve but it's not that bad. There's a lot of "magic", but Python is full of magic.
d0mine 4y ago
Fixture names are globally unique, it makes it easy to find their definitions e.g., dumb-jump in Emacs works: one keystroke to go to the definition or if it is overridden then it shows available options.
- nerdponx 4y ago
  My annoyance is that it's impossible to tell upfront which parameters are fixtures just by looking at the signature of a test function. I would've much preferred an explicit decorator.

epgui 4y ago

I agree with you completely, but... > There are dozens of things that go completely against the philosophy of Python: Explicit is better than implicit. I have found that this is not just true of pytest, but also of the python language! :P

uranusjr 4y ago
It is the _Zen_ of Python. Words are naturally elusive, contradiction is harmony.
- epgui 4y ago
  When coming back from a lisp like Clojure, it feels a bit more like a cacophony, but I agree with you in general haha.
Aperocky 4y ago
> I have found that this is not just true of pytest, but also of the python language! :P Curious as to how? It is pretty explicit and simple when compared against the pack.
- epgui 4y ago
  It depends what's in the pack of comparables... But once you get used to an actually simple language like Clojure or Haskell (neither of which is perfect, but both of which are very very simple) it really is hard to unsee all the accidental complexity of most languages.

Aperocky 4y ago

I have the exact opposite experience, writing tests are actually sort of enjoyable using pytest. The trick might be not using an IDE at all, I consider python and most of its frameworks explicit enough to write with editors like vim. I never found a need to use an IDE for python even when the projects gets larger, because even then the unix tools seemed to work much better at whatever that IDE is doing. This compares sharply against languages in the JVM family.

progval 4y ago
with or without IDEs, you cannot easily tell where fixtures come from. Is it from the same module? same package? a plugin? pytest itself? some non-test module that happened to be imported? You can't tell. And it's a global namespace where everything can override everything else.
- Aperocky 4y ago
  The hierarchy is pretty clearly stated here and it seemed to be against what you're suggesting: https://docs.pytest.org/en/6.2.x/fixture.html#fixture-availability https://docs.pytest.org/en/6.2.x/fixture.html#fixture-availa..., even though I don't think the hierarchy matters much if the fixtures are explicitly placed and named. If you're instantiating the same fixture name across a bunch of different tests, using similar fixtures in different locations and not use import or a central or hierarchical location to define your fixtures after you have accumulated a number of similar items, I find it hard to blame the module for not being explicit.
  - progval 4y ago
    If for some reason a fixture is misbehaving, it's hard to find what package provides it because I don't explicitly import it. I have to use `pytest --fixtures | less` and search for the fixture's name (or `pytest --fixtures | grep -C 50`) > If you're instantiating the same fixture name across a bunch of different tests It means I cannot name my fixture `database`, I have to call it `myplugin_database` instead to make sure it won't conflict with other plugins. And tests using this fixture have the long `myplugin_database` as argument. Python already had namespaces as first-class citizens, it's a shame we have to go back to name prefixes.

sintezcs 4y ago

I am using PyCharm and it perfectly integrates with pytest fixtures. You can navigate to the fixture definition with a click, and it clearly distinguishes fixtures and common arguments.

mrelectric 4y ago
Also works in VSCode with little setup
- maroonblazer 4y ago
  "with little setup" could be construed as "very little" or as the opposite; i.e., some amount of non-trivial setup. Which meaning did you intend?
- kkirsche 4y ago
  The following link describes the set up used / needed by VS Code to integrate the framework with the IDE: https://code.visualstudio.com/docs/python/testing https://code.visualstudio.com/docs/python/testing

eirki 4y ago

I absolutely agree about fixtures-as-arguments thing. Ward does this a lot better, using default values for the fixture factory. There's a long issue on ideas to implement something like that as a pytest plugin (https://github.com/pytest-dev/pytest/issues/3834 https://github.com/pytest-dev/pytest/issues/3834), but it seems the resulting plugin relies on something of a hack.

liendolucas 4y ago

Same feelings here. When I see pytest is like: "oh no...". Been using nose2/unittest for ages and I will continue to do so because is so damn simple. > that it makes learning the library difficult for new comers Not only for newcomers, I've used in the past and if I need to pick it up again I believe I'm going to spend some time refreshing a ton of things and probably get got caught by some caveat. > fixtures are passed as arguments in function Exactly questioned that myself so long ago. Implementing fixture functionality from scratch in Python (even supporting different formats) is only a few lines of code.

packetlost 4y ago

Hard disagree. Pytest is a great. Even with a really basic language support in neovim I have no trouble using it. For newcomers, it does have a learning curve but it's not that bad. There's a lot of "magic", but Python is full of magic.

d0mine 4y ago

Fixture names are globally unique, it makes it easy to find their definitions e.g., dumb-jump in Emacs works: one keystroke to go to the definition or if it is overridden then it shows available options.

nerdponx 4y ago
My annoyance is that it's impossible to tell upfront which parameters are fixtures just by looking at the signature of a test function. I would've much preferred an explicit decorator.