On Nov 9, 7:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > The Djangotestclient exposes theContextused to render the returned > response, so that unit tests can inspect thatContextand 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 alistof dictionaries, > corresponding to theContextat 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 atestwhich 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 tolist, 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; thetestsuite accesses ``request.context`` > dictionary-style, and passes. But a user of django-registration > attempted to run thetestsuite on an installation which uses > inheritance, and saw multipletestfailures as a result: > > http://www.bitbucket.org/ubernostrum/django-registration/issue/3/fail... > > 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.contexteach time atestwill > inspect thecontext, 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 fromlist-style access, since > the former -- in the case of aContext-- will always be using string > keys and the latter will always be using integer indexes.
Hi, I could not find any mention of this in the Version 1.1 features or roadmap. I guess it'll have to wait till next release. Could you please confirm? Thanks, Julien --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
