> 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 somet
On Thu, Jun 24, 2010 at 8:19 PM, JK Laiho wrote:
> Having done some preliminary coding on this, I get the feeling that
> the positive assertion is quite useful, but assertContextNotContains
> is superfluous. Theoretically, you could use it to test that
> unexpected keys don't end up in the context
A very minor note, but...
On Jun 24, 1:31 am, JK Laiho wrote:
> self.assert_('varname' in response.context)
Please use self.assertTrue(). assert_() is deprecated in unittest2.
http://www.voidspace.org.uk/python/articles/unittest2.shtml#deprecations
-Paul
--
You received this message because y
(Looks like I sort of reinvented *args and *kwargs there. Using them
might look nicer, but none of the other assertion methods use them and
I modeled to be in line with them.)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
Having done some preliminary coding on this, I get the feeling that
the positive assertion is quite useful, but assertContextNotContains
is superfluous. Theoretically, you could use it to test that
unexpected keys don't end up in the context dictionary through the use
of locals(), but you shouldn't
While waiting for the patch in ticket #13092 (ContextList objects do
not support "in" operator) to land in Django (hopefully by 1.3), I've
been using a trivial custom method, assertContextContains, to see if
the Context/ContextList of a response object contains a certain key or
a certain key/value
