#14319: Add signals test_setup and test_teardown to Django test suite runner Options -------------------------------+-------------------------------------------- Reporter: jsdalton | Owner: nobody Status: new | Milestone: 1.3 Component: Testing framework | Version: SVN Keywords: | Stage: Unreviewed Has_patch: 1 | -------------------------------+-------------------------------------------- I would like to submit a proposal (with patch) for two new signals to add to the testing framework: a test_setup signal, to be emitted during global test setup, and a test_teardown signal, to be emitted during global test teardown.
Presently, there is no way to modify or add to the global setup or teardown behavior that runs with the built-in test suite runner. This patch provides a hook that applications can use to do that. Each signal is emitted once during a test run. The proposal was discussed briefly on the Django developer's list here: http://groups.google.com/group/django- developers/browse_thread/thread/f45c7302634ed82d Here are a few notes about the proposed changes to source code: * There are really only a handful of lines of code required to make this change. * The most significant change is that the ordering of actions in the `run_tests()` method of `DjangoTestSuiteRunner` has been adjusted. In order for applications to be able to setup connect() calls to the signals, the application code itself has to be imported. This happens for the first time in `build_suite()`, so I swapped the order of the call to `build_suite()` and the call to `setup_test_environment()`. This appears to have no impact, but it's conceivable that some issues could arise if e.g. an application developer did something during import that they expected to be disabled first during testing. At present, the main thing Django does in the `setup_test_enivronment()` call is to disable the email backend, so unless a developer is sending emails in the body of a module or something it shouldn't present a problem. * The second most significant change is that the `django.test.utils` functions `setup_test_environment()` and `tear_down_environment()` calls are executed by connecting to the signal rather than being called directly from the methods of the test runner. This serves as a way to test that the signals are being fired, as Django tests will fail if those two functions do not execute. (Thanks to Russell Keith-Magee for this suggestion). * I have included documentation for these two new signals on the Django signals documentation page. Here are a few arguments in favor of this proposal that I posted to the Django developers discussions: * Requiring a custom test runner to implement this behavior makes it (nearly) impossible for reusable applications to modify global setup and teardown behavior, since it would become the responsibility of the project itself to specify the custom test runner. * The current setup gives the Django core "privileged" access to disable certain features during testing, it would seem that application should be given the capability as well. * Signals are non obtrusive...if they are not used they don't really harm anything. * None of the proposed changes would impact production code, since they are all restricted to the test suite. In fact the patch is really only about a few lines of additional code. There maybe other arguments in favor of or against as well, please feel free to share them if so. -- Ticket URL: <http://code.djangoproject.com/ticket/14319> Django <http://code.djangoproject.com/> The Web framework for perfectionists with deadlines. -- You received this message because you are subscribed to the Google Groups "Django updates" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.
