Add signals test_setup and test_teardown to Django test suite runner Options
|Reported by:||jsdalton||Owned by:||nobody|
|Cc:||adam@…, jsdalton||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||yes|
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:
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.
Change History (16)
Changed 5 years ago by jsdalton
comment:1 Changed 5 years ago by ericholscher
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Accepted
comment:2 Changed 5 years ago by graham_king
- Keywords signals added
- Severity set to Normal
- Type set to New feature
Changed 5 years ago by aseering
comment:5 Changed 5 years ago by jsdalton
- Cc jsdalton added
- milestone changed from 1.3 to 1.4
- Patch needs improvement unset