[dojo-contributors] unit tests: t.assertTrue("foo") fails
savoyboy at gmail.com
Mon Jun 11 22:30:38 EDT 2007
It's interesting to note that with the current behavior this would pass:
But this would not pass:
For consistency's sake, I agree with Brian on this. Unless, of course, there
is good reason behind the way that it is.
On 6/11/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
> In writing some unit tests, I got tripped up by the behavior of
> Doing this works fine:
> But doing this causes an error:
> That feels counter-intuitive to me. I can see where maybe you might
> argue that assertTrue should accept only actual boolean values (true,
> false). But given that assertTrue is designed to accept non-boolean
> values and treat "falsey" values as false, then it seems like "foo"
> should count as non-falsey.
> The assertTrue("foo") call causes an error because assertTrue calls eval
> on the arg. I'm not sure why it does that, but I'm guessing it does
> that so that it can give better error messages. For example, the line:
> t.assertTrue("3 == 8/2");
> results in
> doh._AssertFailure: assertTrue('3 == 8/2') failed
> But, looking at some actual unit tests, it seems like nobody is taking
> advantage of that feature -- people do assertTrue(3 == 8/2) instead of
> assertTrue("3 == 8/2").
> Would it be a good idea to change assertTrue so that it does not call
> Or, if we do want to keep the eval behavior, would it make sense to
> expose that more explicitly? We could have two separate methods:
> doh.assertEval(condition) and doh.assert(condition), where assertEval()
> does if(eval(condition)), and assert() just does if(condition).
> :o) Brian
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors