Re: RfC: WebApps Testing Process

On 4/10/11, James Graham <jgraham@opera.com> wrote:
> On Sat, 9 Apr 2011, Garrett Smith wrote:
>
>> On 4/7/11, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
>>> On Wed, Apr 6, 2011 at 10:28 PM, Garrett Smith <dhtmlkitchen@gmail.com>
>>> wrote:
>>>> I don't have time for this. Ask on comp.lang.javascript.
>>>
>>> Nor do I have time to research the reasoning that underlies your\
>> Uh oh. So the explanations weren't enough, got it, so I tried to head
>> you off in the right direction.
>>
>> https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/3550757564c1f24a?hl=tk#
>> I've outlined some of the fundamental problems I saw in the code. I
>> already made the NUnit suggestion on this list (or was it the public
>> webapps?)
>
> Thanks for soliciting wider review. Do you plan to summarise feedback from
> that list here?

I had not considered doing that.

 I think it is quite likely that I will unintentionally
> forget to check back and see if there are any useful suggestions.
>
> On the subject of assert_NaN; I am quite happy to add that for the since
> being explicit is generally good.
I think you're proposing adding assert_NaN. What should it do and why
would you need it?


assert_NaN( undefined ); // Not a number; not NaN
assert_NaN( +undefined ); // NaN value.

However assert_equals always failing
> when passed NaN would be a likely source of bugs. The two reasonable
> choices seem to be "throw" or "just work". I am not sure what is wrong

Just delete it.

> with "just work". In particular I think it is quite obvious to anyone
> reading what assert_equals(NaN, something) does. Yes,

Remember, your test harness uses TestNG argment order, not JUnit
order. E.g. "actual, expected", not "expected, actual".

And again, a test that does that is a mistake. Quite obvious.
-- 
Garrett

Received on Sunday, 10 April 2011 18:40:46 UTC