On Tue, Feb 10, 2009 at 10:34 AM, Ludvig Ericson
<[email protected]> wrote:
>
> 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.
Erm... no it doesn't. Lines 236-245 of testcases.py:
self.client = Client()
try:
self._pre_setup()
except (KeyboardInterrupt, SystemExit):
raise
except Exception:
import sys
result.addError(self, sys.exc_info())
return
super(TransactionTestCase, self).__call__(result)
That's set client, _pre_setup, super(), not _pre_setup, set client, super().
>> 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.
That's the technique I was referring to. It can be implemented in at
least three ways -
1) Providing a class level variable that defines the Client class to
be instantiated,
2) Providing a method that returns the Client class to be instantiated, or
3) Providing a method that instantiates the client class.
Option (3) is essentially a replacement for setup(), so it's probably
overkill. Personally, I'd be leaning towards (1) - it's easy to
describe, almost impossible to get wrong, and matches the other
configuration options for the TestCase class.
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 [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
-~----------~----~----~----~------~----~------~--~---
