Hi Whilst I appreciate the effort and love pytest, I don't think this it's feasible at the moment to even suggest to users that they use pytest, let alone make it a default or port Django's unittest-based framework.
For a first step, we have our backwards compatibility policy. Any move away from the unittest-based runner would break users' customizations such as subclasses Secondly, pytest-django may seem mature, but it does not have feature parity with Django's test framework. Off the top of my head: - It doesn't run system checks before tests. - It doesn't support a setUpTestData-style shared database fixture with rollback between tests in the "functional" style of tests. - It only has one test database fixture, so it either sets up *all* test databases or none. Django's TestCase supports a "databases" attribute to list the required databases needed in the tests, allowing tests that only use a subset of the databases to only set up those databases. - It doesn't support the TestCase.available_apps attribute. - I don't believe it rearranges TransactionTestCase tests to the end of the test run, allowing them to slow down the run. There are other examples in the pytest-django issues list. Naturally it's the rare edge case, less-used features that few contributors want to work on that are missing - those users who need them find that pytest-django isn't for them and stick with the django testing framework. And there is a fairly limited bunch of people contributing to both pytest-django and django's test framework. Third, pytest itself does not have complete feature parity with the basic run-tests options of Django's test framework. For example, Django has the --reverse flag to run tests in the reverse order. I suggested this be added to pytest core, but it was decided to make it into a plugin instead, pytest-reverse, which I now maintain. I appreciate your willingness to contribute. I think any energy in this space is best focussed on improving pytest-django to improve its feature coverage, and that Django should not have any official support or suggestion to use pytest-django at this time. We could perhaps link to pytest as an alternative in one of the test topic guides, however we do tend to avoid such documentation links since they are prone to bitrot. Thanks, Adam On Tue, 15 Dec 2020 at 15:49, Diptesh Choudhuri <diptesh.choudh...@gmail.com> wrote: > Thank you everyone for your inputs! I don't know how you all are using the > quote feature, so I will address you all by your names. > > > - *Jacob*: Thank you for your support! The ticket you linked to is > very helpful. It is upside of 5 years old. *pytest *has evolved a lot > over that time, as has django itself. The points raised in the ticket > itself are still valid 5 years later and as django is a mature project now, > some of its development prowess must go to specifically fixing its > weaknesses (I believe the default runner is one). That being said, I also > opened another ticket on the same website today about this. Should I close > that and bump the one you linked instead? > - *Tobias*: I understand most of the issues raised are personal > preferences. However these preferences have been cultivated by the django > community itself, so it would be safe to assume that a lot of django users > would have the same preferences. There is no harm in making these > preferences official (by including them in the official docs). Once people > have a common convention to follow, they will only appreciate it because it > makes their lives easier. *pytest *indeed does a lot of magic behind > the scenes but I intend to demystify this by writing extensive > documentation in the *Advanced Testing *Topics page in the django > docs. As for the *subTest *method, I admit to not having done enough > research about it and it is completely new to me. However, since its not in > common usage, we can safely assume that people don't like using it, don't > you agree? > - *Tom*: Totally agree with everything you said! Especially being able > to write more "pythonic" code with *pytest*. Even though our > definitions of pythonic might be different, I would boldly suggest that > functional testing, which *pytest *prefers, looks much more beautiful > and readable than unittest's. class based ones. > - *René: *Though the option exists, I would humbly argue that its much > easier to invoke *pytest *than it is to invoke *python manage.py test*. > Most of my focus would be on improving the docs, along with a few changes > to code-base itself to make pytest the default and generate a sane > *pytest.ini*. On further thought, we can completely remove *pytest.ini > *and instead do all configuration from *settings.py *itself. Though > *pytest-django > *exists, I feel that it can be very unforgiving to users who are > completely new to testing (I was one not long ago). It doesn't work right > out of the box. I sincerely believe this must and should be worked upon. > > Thank you everyone for your inputs and I would love to hear some more > feedback. Also if anyone could teach me how to use the quote function, I > would highly appreciate it. > > Best > Diptesh > On Tuesday, December 15, 2020 at 8:47:24 PM UTC+5:30 > re...@fleschenberg.net wrote: > >> Hi, >> >> On 15.12.20 15:48, Tobias Bengfort wrote: >> > My issue is mostly that pytest uses a lot of magic that is hard to >> > debug, e.g. the overwritten assert statement or implicit injection of >> > fixtures. Most pro arguments seem to depend on personal taste. >> >> It should be noted that you can use pytest / pytest-django as a test >> runner without having to use any other pytest features (it can run >> unittest-style tests, you don't have to rewrite them). I do think it has >> some features in the test runner. For example, the -k command line >> option to quickly select tests, or --last-failed to rerun failed tests. >> >> However, since pytest-django exists and has been working flawlessly for >> me for several years, I am not sure how much benefit there would be in >> having this in Django itself. >> >> Regards, >> René >> > -- > 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/64886590-2d95-4c11-ad8d-24d0a746001dn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/64886590-2d95-4c11-ad8d-24d0a746001dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- 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/CAMyDDM3mQD_p4Mk6is-go%3DGeBWZr_K6e3oBrj0ZkW6-00tSbsA%40mail.gmail.com.
