Re: RfC: WebApps Testing Process

On Sun, 10 Apr 2011, Garrett Smith wrote:

> 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 would find it helpful, but if you don't I will try to check there.

> 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.

It would assert that the argument has the IEE 754 Not A Number value. 
Presumably one would need that if a function was expected to return NaN in 
some circumstances. One often needs this when testing ES itself, although 
that is out of scope for us. An example of this functionality being needed 
for testing DOM is to check that a structured clone preserved NaN values 
as expected.

Of course in the current form, one could use assert_equals to do this.

> 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.

Just delete what?

>> 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".

True story: the test harness I wrote before testharness.js used the 
opposite argument order which I find more natural. I was told that people 
in general found the (actual, expected) argument order more natural, so I 
adopted it. This makes things more confusing for me but hopefully less 
confusing for everyone else.

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

How would you write a test that a structured clone correctly preserves 
NaN values?

Received on Sunday, 10 April 2011 19:28:36 UTC