Russell Keith-Magee wrote: > On 9/5/07, Gary Wilson <[EMAIL PROTECTED]> wrote: >> Gary Wilson wrote: >>> Russell then added the comments: >>> ------------- >>> My hesitation here (and the reason I didn't include a 'context assert' in >>> the >>> first place) is that assertContext does an Equals test, but doesn't provide >>> a >>> way to do any other assertion - NotEquals?, True, False, LessThan?, etc. We >>> could get around this by adding assertContextEquals, assertContextNotEquals, >>> and so on, but that is really just duplicating the underlying assertion API. >>> This is certainly possible, but I'm not convinced it is the best approach.
In my implementation of assertContext, I pretty much followed what was going on in assertFormError; however, I realized while writing some tests today at work that yes, it would be nice to have all the other assertions available. So whatever gets decided on for an assertContext solution should probably also get applied to assertFormError, IMHO. >>> An alternate approach would be to provide a utility function to get the >>> value >>> of a context variable from the list of contexts in a response. This would >>> allow the use of all the standard assert methods. However, I'm not entirely >>> sure where such a utility function should go. Putting it on the TestCase? >>> itself rubs me the wrong way. >>> ------------- >> What would happen in the case where the same variable name is used in >> multiple >> contexts with different values in each context? > > Valid point - however, in practice, the same context is passed to > multiple templates. There are some edge cases (e.g., a view with two > calls to render_to_template) where this isn't the case, but I wouldn't > consider them to be the common case. Template tags that make use of a template maybe a more common case, but it's probably better to be testing those at a lower level anyway. > I suppose we could have the context-extracting helper method raise an > exception in the case of multiple values, or return a tuple in the > case of multiple values. However, I'm not particularly enamoured with > either of those suggestions. What if we make make response.context always just a single item of the first context used for rendering (and move the storage of the full list of contexts to response.contexts). The majority of the time, you're wanting to test just that first context anyway. The context(s) used for extended templates is uninteresting since it's the same as the outer context. So this would allow for all the existing assertions to be used: self.assertEqual(response.context['title'], 'hello world') self.assertNotEqual(response.context['title'], 'goodbye world') ... And if we want, we can add the assertContext (or assertContextContains) for when you need to go deeper than the first context. But in this case, you would be limited to just checking that _any_ context used contains the specified context variable with the specified value (the way it's coded in the patch). Test would look like: self.assertContextContains(response, 'title', 'hello world') I think this would do a good job of making the simple case simple and the complex case possible. Thoughts? Gary --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
