The Django test client exposes the Context used to render the returned response, so that unit tests can inspect that Context and verify that it contained what it was expected to contain. This is all well and good, except that there is no consistent way to write tests which do this.
When an inheritance chain of multiple templates is used to render the response, ``response.context`` is a list of dictionaries, corresponding to the Context at each template and so, for example, one might want to check ``response.context[0]['some_var']``. But when inheritance is not used, ``response.context`` is simply a dictionary, leading to a check lik ``response.context['some_var']``. This makes it extremely difficult/tedious to write truly portable unit tests, since a test which passes on one installation of an application might fail on another for no other reason than that the type of ``request.context`` has changed from dictionary to list, or vice-versa, raising spurious ``TypeError`` or ``KeyError`` depending on which way it changed. For a real-world example, consider django-registration: I have a local project set up to run its unit tests, with minimal (non-inheriting) templates; the test suite accesses ``request.context`` dictionary-style, and passes. But a user of django-registration attempted to run the test suite on an installation which uses inheritance, and saw multiple test failures as a result: http://www.bitbucket.org/ubernostrum/django-registration/issue/3/failed-in-test I believe quite strongly that unit tests, if they are to be useful, need to be portable. And currently, it seems the only way to make them portable is to include type checks on response.context each time a test will inspect the context, e.g.,:: if isinstance(response.context, list): self.assertEqual(response.context[0]['foo'], 'bar') else: self.assertEqual(response.context['foo'], 'bar') This is painful and ugly. For 1.1, could we look into unifying the interface to ``response.context`` to avoid this sort of problem? Unless I'm thinking about this the wrong way, it shouldn't be too hard to differentiate dictionary-style access from list-style access, since the former -- in the case of a Context -- will always be using string keys and the latter will always be using integer indexes. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
