Note also, that sometimes the context that you are looking for isn't always
in [0]. I ran into this when I was writing testmaker, and had to hack around
it. Luckily all of my templates used inheritance, so I didn't get bitten by
the dictionary or list of dictionary part.
I did something like this:
con = context.dicts[0]
if 'MEDIA_URL' in con:
con = context.dicts[-1]
Obviously a hack, but it seems to work most of the time.
For my pony request, it would be really nice to have a way to get "user
defined" context. This being things that were passed from views, set in
template tags, (and maybe other places?). That is what the above code is
trying to do. I haven't thought about how to do it, but I agree with James
that some thought needs to be placed into this.
A simple workaround might be to flatten the lists in request.context, but
then keys in the dictionaries might be overwritten.
On Sat, Nov 8, 2008 at 2:56 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> 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."
>
> >
>
--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
