> Sorry, but this looks like a bit of a mess to me. It looks like you're
> cramming three different assertions into a single assertXXX method.
> I'm not sure I see why this is a good thing.
Three separate assertion statements, yes, but all of them basically
doing the exact same assertion (is something or are some things in the
context), just for different inputs. I suppose it comes down to
personal preference: If I have a method called assertContextContains,
I like to be able to give it different types of inputs (single keys, a
list of keys or a dictionary of keys/values) and just have it do "The
Right Thing" in each case. But, YMMV and varying tastes, as I
expected.
> 1) I don't see the advantage to providing an alternate implementation
> of self.assertTrue('x' in context)
Individually, it would make no sense, that's correct. But as a part of
a method that can take various different inputs and check for their
existence in the context, it's mandatory to include.
> 2) Asserting that many variables exist in the context can be done
> with multiple calls to (1), or if you want to conserve bytes, using
> self.assertTrue(all(var in context for var in ['x','y','z']))
Ah, I was unaware of the existence of the all() method. Good to know.
That alone almost completely obviates the need for a "multi-input"
method, leaving only the third form:
> 3) Asserting that key-value exists in context has been proposed
> previously - see #5333 for the proposal, and why it was rejected
Oddly, that ticket didn't turn up when I searched Trac (while #13092
did). Anyway, I tested the method against various sets of real-world
context data I had lying around in old view code, and it did work as
advertised in all of them. I'll probably keep it around in my own
toolkit just for this key-value purpose, but having read the comments
of that ticket I understand why it wouldn't necessarily make sense on
the framework level as part of the standardized, supported set of
assertion methods.
Thanks for the feedback! Live and learn :-)
- JK Laiho
(Thanks also to Paul McMillan about the deprecation info, didn't know
about that either.)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
