I recently asked a question on Django Users related to executing
certain code during the global setup and teardown routines that run in
Django's test runner. In my particular use case, I was looking for a
hook where I could disable some third party API code when tests
execute, in much the same way that Django itself swaps out the email
backend during testing to ensure no emails are actually sent.
Anyhow, it seems the only solution at the time being is set up a
custom test runner, which is what I ended up doing. However, it
occurred to me that a more elegant approach would be to use signals
that run during setup and teardown, which applications could hook into
if they needed to do any global setup or teardown actions. To me, this
seems like an excellent solution to the problem (it's actually what I
implemented in my custom test runner I ended up using).
I wonder if this is something that would be considered for addition to
the core? I at least wanted to throw it out there for discussions.
I've included a patch I wrote to implement this in the core test
module, at the bottom of this message. It should be mostly self
explanatory. Note that the call to send the test_setup figure has to
occur after get_apps() has executed in build_suite(), since
applications aren't loaded until then and any signal connections would
not yet have had a chance to be set up.
Just a few arguments to throw out in favor of this idea:
* 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 5 lines of additional code.
Anyhow, hopefully this is something you guys would be interested in
considering. Apologies if this topic has been discussed or proposed
before, but in searching I could not find anything related to it.
Proposed patch:
Index: test/simple.py
===================================================================
--- test/simple.py (revision 13861)
+++ test/simple.py (working copy)
@@ -7,6 +7,7 @@
from django.test import _doctest as doctest
from django.test.utils import setup_test_environment,
teardown_test_environment
from django.test.testcases import OutputChecker, DocTestRunner,
TestCase
+from django.test.signals import test_setup, test_teardown
# The module name for tests outside models.py
TEST_MODULE = 'tests'
@@ -246,7 +247,11 @@
else:
for app in get_apps():
suite.addTest(build_suite(app))
-
+
+ # This signal can't come any earlier, because applications
are actually loaded
+ # in get_apps()
+ test_setup.send(sender=self)
+
if extra_tests:
for test in extra_tests:
suite.addTest(test)
@@ -284,6 +289,7 @@
connection.creation.destroy_test_db(old_name,
self.verbosity)
def teardown_test_environment(self, **kwargs):
+ test_teardown.send(sender=self)
teardown_test_environment()
def suite_result(self, suite, result, **kwargs):
Index: test/signals.py
===================================================================
--- test/signals.py (revision 13861)
+++ test/signals.py (working copy)
@@ -1,3 +1,6 @@
from django.dispatch import Signal
template_rendered = Signal(providing_args=["template", "context"])
+test_setup = Signal()
+test_teardown = Signal()
+
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
