Slightly OT... We've got similar assertion functions on a custom testhelper at work and we haven't had any problem with the "sometimes you feel like a list, sometimes you don't" nature of test responses and test contexts.
I was actually going to re-work our custom testhelper a bit (clean up some cruft) and send in a patch if folks would be interested in having more custom assertions and helper functions on the TestCase class? Thanks, Chris H. On 7/15/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 7/15/07, oggie rob <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > Playing around with the test client I found it frustrating that > > "context" can either be a single context or a list, depending on how > > the template is rendered. My feeling is they should always return > > lists. Likewise for the "template" field. I can see that no matter > > what there is a chance of the test breaking unexpectedly but I think > > it would happen less & coding would be simpler if those always > > returned lists. > > > > Should I write up a patch for this or is there a benefit to the > > current approach that I can't see? > > The benefit I can see is that testing the simple case (single > template/context) is very simple - you don't have to iterate over a > list of one - and there shouldn't be a common need to genericize this > code (i.e., write tests that could expect single _or_ multiple > templates). > > When you're writing a test, you should know exactly which template is > going to be rendered, so there shouldn't be any surprises in what you > get back in response.template. If you know you only used one template, > you should be able to write your test to match expectations. If I'm > missing an obvious use case here, feel free to enlighten me. > > On top of this, I can't say I've seen anything other than 'toy' > examples using a single template. All my templates for any given site > extend a 'base.html', so In practice, I don't ever see a single > template in the tests. If your experience with this differs, I'd be > interested to know why. > > I'm not completely opposed to changing this. However, there is a > backwards compatibility issue with making this change. This will > invalidate any existing single-template tests. Now, the docs do warn > that the testing system is subject to change, but that doesn't give > license to change things arbitrarily. There needs to be a good reason > for change, as well as a general community consensus. > > One issue to consider is the importance of making the change, > especially given the availability of assertTemplateUsed, > assertContains and family. These assertions wrap the need to access > response.templates, etc. I haven't had much (any?) need to access > response.context and response.template directly since these assertions > were added. Given that they hide the 'complexity' of the datatype > used, there is a much reduced need to change existing behavior. > > If you have additional needs for assertion testing, I'd be interested > to know them. The existing assertion set is drawn from what I have > needed to test my own applications, and I make no claim that they are > a spanning set. > > Yours, > Russ Magee %-) > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
