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.
