On Sat, Jan 5, 2013 at 9:11 AM, Shai Berger <[email protected]> wrote:
> On Friday 04 January 2013, Malcolm Box wrote:
> >
> > The general pattern I want to implement is have a test client that makes
> > assertions about all the requests made during a set of tests. For
> example,
> > it could check that every get() returned cache headers, or that
> > content_type is always specified in responses. Or that the response has
> > certain HTML, uses certain templates etc - ie all of the assertion
> testing
> > goodness in django.test.TestCase.
>
> <snip>
> >
> > def test():
> > r = self.client.get(...)
> > self.check_response(r)
> >
> > but this is error prone, verbose etc etc.
> >
> > The right thing is that within a test suite, the get()/post() etc to do
> the
> > checks for me - and so it should be possible to create a testclient that
> > does this, and be able to use this testclient in various test suites.
> >
>
> No, you're mixing concerns.
>
> > Is there a simple, clean way to solve this that I'm missing?
> >
>
> class MyTestCase(TestCase):
>
> def check_response(self, response):
> self.assertContains(response, ....)
>
> def checked_get(self, *args, **kw):
> r = self.client.get(*args, **kw)
> self.check_response(r)
> return r
>
> class SpecificTest(MyTestCase):
>
> def test():
> r = self.checked_get(...)
> ...
>
> That's how I would do it.
>
>
Which is lovely, right up to the point where someone writes a test with:
self.client.get(....)
Extremely likely to occur (in fact 100% probable in any sizeable test
suite), won't show up as an error and yet suddenly the tests aren't testing
what they should be.
I don't understand your "mixing concerns" argument - the concern of the
TEST client should be testing just as much as it's the concern of the
TESTcase and TESTsuite. The hint is in the name :)
Now if the test client was truly decoupled (ie expected to be used in other
places) then I'd totally agree with you/Russ about mixing concerns and
coupling. But AFAIK it's not - it's explicitly a utility that does all
sorts of jiggery-pokery to support testing. Adding a parameter to the
initialiser seems a very minor sin (if a sin at all) in comparison.
However, if I'm not convincing anyone I'll shut up about this - the "fix"
is simply:
class Tests(TestCase):
def setUp(self):
self.client = MyBetterTestClient(self)
(although this does then require any derived test case to remember to call
super(Derived, self).setUp(*args, **kw))
I'd just have liked to be able to do that using the existing machinery:
class Tests(TestCase):
client_class = MyBetterTestClient
Cheers,
Malcolm
--
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.
