On 9/5/07, Gary Wilson <[EMAIL PROTECTED]> wrote: Apologies for taking so long to get back to you on this one, Gary - I've been snowed under with other things.
> 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. > > > > 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. 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. > Do the various other assert > methods (True, False, etc.) even make sense in that case? The other assert methods still make sense (or at least as much sense as equals makes). The interpretation of your proposed implemention is essentially 'does key X _ever_ take the value of Y'. This could be equally applied to any other assertion. However, I'm not really a fan of that approach as a test construct. If you had a multiple-value-for-context-key case like the one you describe, your test would pass True for both values. IMHO, tests should have a single value for which they will pass; the logic you propose leaves the door open for multiple affirmative return values for the test. > On a related note, is the lack of some sort of assertContext method the reason > why in django.test.client.Client.request that we are flattening out a > single-item list of templates and contexts to the single item? I ask because > in the TestCase code, we are turning the single item back into a single-item > list. Could we just keep it a list and forgo the flattening and unflattening? As I recall, the reason was to make the simple case simple, while the complex case remained possible. In practice, the 'simple case' of a single template, single context has been (in my experience) almost non-existent - any non-trivial template uses inheritance, which automatically causes a second context evaluation. This would be a backwards incompatible change, albeit a low impact one (since the single context case is, in practice, fairly rare). However, I would still need to see a compelling reason for the change - such as a good model for context assertions - before I would support changing the current behaviour. 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 [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 -~----------~----~----~----~------~----~------~--~---
