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.
