[dojo-contributors] unit tests: t.assertTrue("foo") fails

Michael Smith 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:
     t.assertTrue("true");

But this would not pass:
     t.assertTrue("false");

For consistency's sake, I agree with Brian on this. Unless, of course, there
is good reason behind the way that it is.

~Michael


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
> doh.assertTrue().
>
> Doing this works fine:
>    t.assertTrue(333);
>
> But doing this causes an error:
>    t.assertTrue("foo");
>
> 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
> eval?
>
> 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
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070611/24e8ca35/attachment.htm 


More information about the dojo-contributors mailing list