I would be very much in favour of this. The developer experience of pytest is far better than the unittest module, the tests look more Pythonic and there is a lot more of an ecosystem we can tap into.
There was some recent work done about adding timings to the Djanfo test suite as part of the multi-process test runner. This was way more difficult than it should have been. Unittest, along with the logging module, are very old and archaic stdlib modules that are ok-ish, but definitely hobbled by legacy interfaces and a “Java inspired” pre-pythonic code style. I think it’s safe to say that most of the Python ecosystem has settled on pytest, and if we go along with that as well then we can reduce our maintenance burden whilst making our users happier. Tom > On 15 Dec 2020, at 13:52, Diptesh Choudhuri <diptesh.choudh...@gmail.com> > wrote: > > Though the django default runner gets the job done, I think its high time to > leverage the power of dedicated frameworks for testing django apps. I will > take up the case of pytest here because other frameworks like nose are not > widely used. > > For everyone who has used pytest for testing in django, I think we will all > agree that pytest is much better suited to this task. > The passing tests look better. > Failing tests are much more verbose with where the error actually occurred. > Parameterizing the test cases using the default runner requires a third party > library and looks difficult (I will be honest, I haven't used this package > myself at all). > Injecting runtime conditions into the tests is quite difficult, if not > impossible, and requires a lot of hacky workarounds. > I am not sure about this, but the default runner also doesn't cache results > from previously run tests, making retesting unchanged tests much slower. > This might sound non-trivial but typing pytest is much more easier than > typing python manage.py test into the command line. > IDEs like VSCode can discover tests written for pytest but not the ones > written using the default runner. This might not sound a big deal, but it is > infinitely more easier to run tests using the GUI that these IDEs have. They > provide real-time feedback and show exactly which tests have passed and what > haven't in the code source itself. Here is a picture showing what I mean. > The directory structure created by python manage.py startapp my_app creates a > tests.py file. This goes against testing best practices which say that all > tests should be aggregated at one place (as opposed to inside individual > apps). > A single tests.py file encourages new, inexperienced developers to write all > their tests in a single file. This, yet again, goes against testing best > practices which put a lot of emphasis on modularization of tests. Models > should be tested in test_models.py, views in test_views.py etc. > Though unittest's setUp and tearDown work fine, I personally find that > pytest's fixture system provides a bit more freedom. I might want to put all > my test methods in one class, but I might not want to run the setUp and > tearDown for every test method. (Let me know if this point is a bit unclear.) > pytest and pytest-django are quire mature frameworks and don't need a lot of > changes. We could make it easier to setup tests right out of the box. For > example, django-admin startproject my_project could create a pytest.ini right > out of the box in the project root. > > Most of my focus would be on rewriting and adding documentation. Even though > widely used, pytest and pytest-django are pretty difficult to get started > with for a newbie. I intend to fix this by adding a lot of examples to the > docs (maybe even make a separate repository for this). > > NOTE: I intend to work on this project for GSoC 2021. I am just scouting > beforehand to see how the community receives it. > > Please let me know what you think of this idea. Any critiques will be welcome. > > Best, > Diptesh > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/8c5e0baa-5104-4876-a936-8792b3c8d5b8n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/FDB4BE6D-226A-4B23-8A75-27267EC500D3%40tomforb.es.
