Hi Diptesh, This is a great idea! (And one that has had a fair bit of discussion). I don't think anyone holds an opinion against supporting pytest as a testing tool, but I believe the main hurdle is laying a convincing argument why this support should be in Django Core versus remaining in its current third-party state. I personally believe it should be in core because a lot of custom features we'd like to add to the test runner already exist in pytest's rich ecosystem. Just as Tom mentioned, adding timings was a lot harder than expected while such a feature already exists in pytest.
If we aren't going to add it to core, the question I'd like to raise (and preferably get an answer from experienced pytest-django users/developers) is what changes can we make in core to make it easier for the pytest-django package. Lastly, if you intend to purely write documentation, I would recommend you apply for next year's Google Season of Docs instead of Google Summer of Code. It would be a better fit for the job description On Tue, Dec 15, 2020 at 3:52 PM 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. > > 1. The passing tests look better. > 2. Failing tests are much more verbose with where the error actually > occurred. > 3. Parameterizing the test cases using the default runner requires a > third party library and looks difficult > > <http://witkowskibartosz.com/blog/parameterized-django-testcases-at-biking-endorphines.html> > (I > will be honest, I haven't used this package myself at all). > 4. Injecting runtime conditions into the tests is quite difficult, if > not impossible, and requires a lot of hacky workarounds. > 5. 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. > 6. This might sound non-trivial but typing *pytest *is much more > easier than typing *python manage.py test *into the command line. > 7. 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 > <https://imgur.com/a/5HKE678> is a picture showing what I mean. > 8. 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). > 9. 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. > 10. 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 > <https://groups.google.com/d/msgid/django-developers/8c5e0baa-5104-4876-a936-8792b3c8d5b8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJNa-uO8ejAVJsKuFgf6RERVZRR_2pT49DvCJZwOzhx6E-QR6w%40mail.gmail.com.
