Feb 8, Russell Keith-Magee:
> First off - it isn't impossible to do what you are describing with the
> existing setup. There is no reason you couldn't override _pre_setup()
> in your subclass and either re-instantiate self.client, or modify the
> self.client instance that has already been created. This isn't
> necessarily clean, but it would work.
Though I solved my own problem through some means, no - your
suggestion would not work. The reason is that the TestCase.__call__
code does: _pre_setup, set client, super...(), _post_setup.
The only way to hook into that code would be to mash up the MRO for
TestCase and inject oneself into the super call. And then re-instatiate.
> This area could certainly be cleaned up, though. Moving the
> instantiation of Client into _pre_setup() would be one approach.
> Another would be to parameterize the class that is instantiated when
> the client is created - i.e., rather than always instantiating
> django.test.client.Client, we provide a customization hook that lets
> subclasses provide their own Client class.
A rather common idiom I've seen is:
class TestCase(...):
client_class = DjangoTestClientThing
def __call__(self, ...):
# ...
if self.client_class:
self.client = self.client_class(...)
# ...
Essentially achieving the same as you, only because of Python's name
resolution machinery, you could also do `my_inst.client_class = Blah`
to specialize per instance.
> Patches welcome. :-)
Once I know what to write!
- Ludvig
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
