At present, we have a number of functions in django.test.utils which aren't documented and are meant for use in Django's test suite. Things like:
* extend_sys_path() * isolate_lru_cache() * captured_stdout()/err()/in() * freeze_time() * require_jinja2() I have the need to reuse a WidgetTestCase from forms_tests in postgres_tests so I tentatively proposed putting it in django/test/testcases.py with a comment that it's not a public API [0]. Simon proposed creating a django/tests/tests/utils.py submodule (alongside runtests.py) instead of defining it in django.test since it's not meant to be a public API. Do you have any feelings about how to best organize things? I agree that mixing public and private things in django.test is not ideal. Another idea I had was to create something like django/test/_utils.py (underscore prefix) for private stuff. That would allow user code to continue using private APIs at their own risk (whereas putting test helpers in tests/ would not). [0] https://github.com/django/django/pull/8425 -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/93178ea8-add8-4d40-96db-871ba12efa19%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
