4 ms·

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

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.
    - Aperocky 4y ago
      > I cannot name my fixture `database`, I have to call it `myplugin_database` instead On the subject of implicit vs explicit, `myplugin_database` is unquestionably more explicit.
    - Timon3 4y ago
      I just ran into the fixture problem myself, maybe you can help me understand how I could find this myself. I wanted to integrate pytest-benchmark[1]. Their docs mention fixtures a couple of times, but the examples only show that test functions receive a magic untyped parameter called "benchmark". How would I make my usage more explicit? Can I somehow explicitly import the fixture, or at least type it? [1] https://pytest-benchmark.readthedocs.io/en/latest/index.html https://pytest-benchmark.readthedocs.io/en/latest/index.html
      - progval 4y ago
        I don't think you can do better than make pytest-benchmark a dependency
systemvoltage 4y ago
> I have the exact opposite experience, writing tests are actually sort of enjoyable using pytest. Yes, likewise after you understand how it works. It's great. That's not what I am arguing about. Pytest could have been designed more explicitly while retaining it's advantages. I am a huge fan of how I can just use "==" operators to test equality. The UX of pytest is great after you know how it works.

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.
  - Aperocky 4y ago
    > I cannot name my fixture `database`, I have to call it `myplugin_database` instead On the subject of implicit vs explicit, `myplugin_database` is unquestionably more explicit.
  - Timon3 4y ago
    I just ran into the fixture problem myself, maybe you can help me understand how I could find this myself. I wanted to integrate pytest-benchmark[1]. Their docs mention fixtures a couple of times, but the examples only show that test functions receive a magic untyped parameter called "benchmark". How would I make my usage more explicit? Can I somehow explicitly import the fixture, or at least type it? [1] https://pytest-benchmark.readthedocs.io/en/latest/index.html https://pytest-benchmark.readthedocs.io/en/latest/index.html
    - progval 4y ago
      I don't think you can do better than make pytest-benchmark a dependency

systemvoltage 4y ago

> I have the exact opposite experience, writing tests are actually sort of enjoyable using pytest. Yes, likewise after you understand how it works. It's great. That's not what I am arguing about. Pytest could have been designed more explicitly while retaining it's advantages. I am a huge fan of how I can just use "==" operators to test equality. The UX of pytest is great after you know how it works.