id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
14319	Add signals test_setup and test_teardown to Django test suite runner Options	Jim Dalton	nobody	"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."	New feature	closed	Testing framework	dev	Normal	wontfix	signals	adam@… Jim Dalton	Accepted	1	0	0	1	0	0