On Sat, Sep 18, 2010 at 12:49 AM, Jim D. <jim.dal...@gmail.com> wrote: > 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 don't remember this being raised in the past, but it seems like a reasonable proposal to me -- in particular, because of this: > * 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. This is the argument that resonates with me. The patch you provide is a good proof-of-concept, but it needs a little bit more work before it is trunk-ready. In particular: 1) For consistency, the existing setup/teardown code should use this signal. This then doubles as a test for the new signals, since the email tests won't pass unless the test setup signal is working. 2) The signal (and the resulting changes to setup/teardown procedures) need to be documented. Don't get too hung up on getting the language perfect -- a good first draft in the right location will suffice. There are two sets of documentation changes -- adding the test signals to the signal index, and documentation in the test docs about how/when to use the signal in practice. Yours, Russ Magee %-) -- 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.
