*Ahmad*, thanks for your views! Here's what I think. > 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. Adding to this, since features like this already exist in *pytest*, I don't think we should reinvent the wheel and try to implement them from scratch.
I would say the main reason I would like integrate pytest into the django core is that since it is much loved among the community, it only makes sense to make it official. New users won't have to wrack their heads over unittest's basics (it took me a long time to understand *setUp *and *tearDown *and even longer to actually use it in a project). *pytest-django *also requires you to write much less code for the actual test (compare *self.assertEquals(thing1, thing2) *with *assert thing1 == thing2*). I don't intend to write documentation only. I believe this idea has a lot of scope, and by integrating the features I have already suggested and the ones that will be suggested in the near future, I will end up writing a lot of code. So it will fit GSoC's job description. However I thank you for mentioning Google Summer of Docs, I will definitely look into it. On Tuesday, December 15, 2020 at 9:15:47 PM UTC+5:30 Ahmad A. Hussein wrote: > 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....@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-develop...@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/fc37d484-9437-47f2-87db-124f470653adn%40googlegroups.com.
