pytest?

[tony]

@kislyuk Are you willing to have a PR for test/test.py rewritten in py.test style?

py.test would make the tests way more cleaner than unittest

I switched from unittest to py.test on my projects years ago and its excellent:

• https://github.com/tmux-python/tmuxp/pull/151/files, example: unittest vs pytest

[kislyuk]

Thanks, but no, we are fine with unittest.

[tony]

@kislyuk Will you go into this a bit more? Any concerns I can address? (Think it'd add complication packaging / test wise or be more harm than good, somehow?)

FYI I'm not unbiased, I'll admit I'm pro-py.test

[kislyuk]

I prefer to use standard library packages unless there is a very good reason not to. I don't see anything wrong with unittest, I disagree that pytest would make the tests cleaner, and I find the pytest fixtures loading system (especially autoload fixtures and the shadow fixture namespace) to be opaque and unintuitive to the point where I get very frustrated with pytest as a whole.

[tony]

and I find the pytest fixtures loading system (especially autoload fixtures and the shadow fixture namespace) to be opaque and unintuitive to the point where I get very frustrated with pytest as a whole.

yes pytest employs magic.

It is still possible to create an impenetrable web of autouse fixtures and make testing impossible. I've forgotten the times I've experienced this - I've since changed to using autouse=True very conservatively and keep fixtures in a root conftest.py. I also avoid pytest markers - the side effect is too hard to trace.

Test collection in pytest is indeed complex, especially if @pytest.fixture's autouse=True has side effects impinging on test runs. Fixture availability is intuitive - based on module depth, for the most part - conftest.py(s) being a critical aspect of most test suites - but the benefit is it makes it easy to search for the file and find where the fixtures are at by checking adjacent (then traversing up directories) from the test file.