It&#39;s interesting to note that with the current behavior this would pass:<br>&nbsp;&nbsp;&nbsp;&nbsp; t.assertTrue(&quot;true&quot;);<br><br>But this would not pass:<br>&nbsp;&nbsp;&nbsp;&nbsp; t.assertTrue(&quot;false&quot;);<br><br>For consistency&#39;s sake, I agree with Brian on this. Unless, of course, there is good reason behind the way that it is.
<br><br>~Michael<br><br><br><div><span class="gmail_quote">On 6/11/07, <b class="gmail_sendername">Brian Douglas Skinner</b> &lt;<a href="mailto:skinner@dojotoolkit.org">skinner@dojotoolkit.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In writing some unit tests, I got tripped up by the behavior of<br>doh.assertTrue().<br><br>Doing this works fine:<br>&nbsp;&nbsp; t.assertTrue(333);<br><br>But doing this causes an error:<br>&nbsp;&nbsp; t.assertTrue(&quot;foo&quot;);<br><br>
That feels counter-intuitive to me.&nbsp;&nbsp;I can see where maybe you might<br>argue that assertTrue should accept only actual boolean values (true,<br>false).&nbsp;&nbsp;But given that assertTrue is designed to accept non-boolean<br>values and treat &quot;falsey&quot; values as false, then it seems like &quot;foo&quot;
<br>should count as non-falsey.<br><br>The assertTrue(&quot;foo&quot;) call causes an error because assertTrue calls eval<br>on the arg.&nbsp;&nbsp;I&#39;m not sure why it does that, but I&#39;m guessing it does<br>that so that it can give better error messages.&nbsp;&nbsp;For example, the line:
<br>&nbsp;&nbsp; t.assertTrue(&quot;3 == 8/2&quot;);<br>results in<br>&nbsp;&nbsp; doh._AssertFailure: assertTrue(&#39;3 == 8/2&#39;) failed<br><br>But, looking at some actual unit tests, it seems like nobody is taking<br>advantage of that feature -- people do assertTrue(3 == 8/2) instead of
<br>assertTrue(&quot;3 == 8/2&quot;).<br><br>Would it be a good idea to change assertTrue so that it does not call eval?<br><br>Or, if we do want to keep the eval behavior, would it make sense to<br>expose that more explicitly?&nbsp;&nbsp;We could have two separate methods:
<br>doh.assertEval(condition) and doh.assert(condition), where assertEval()<br>does if(eval(condition)), and assert() just does if(condition).<br><br>:o) Brian<br><br><br>_______________________________________________<br>
dojo-contributors mailing list<br><a href="mailto:dojo-contributors@dojotoolkit.org">dojo-contributors@dojotoolkit.org</a><br><a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">http://dojotoolkit.org/mailman/listinfo/dojo-contributors
</a><br></blockquote></div><br>