Re: RfC: WebApps Testing Process

On Thu, 7 Apr 2011, Garrett Smith wrote:

> On 4/7/11, James Graham <jgraham@opera.com> wrote:
>> In general one needs all sorts of typechecking to *not* write methods
>> that will accept any of string, number, etc.
>
> Missing the point. The test harness function expects (it is designed
> to take) any of number, string, host object, etc. Too general. There
> is a difference between that and designing a method that expects a
> string,
>
> e.g. function padString(s, indent) { s = String(s); }

This example doesn't seem to have any relevance to the testharness. I 
would appreciate it if you could use real examples of code you would like 
to change in the test harness. As it is, I am having trouble meshing your 
views with the actual code which, as far as I can tell, is generally quite 
strict about types whilst not bloating the API too much and still feeling 
like javascript.

> No, but more recent browsers do not agree on such things as
> callability of HTMLFormControlsCollection, and, if callable, what the
> result of typeof should be (ECMA says it must be "function").

The only place I can see that the test harness relies on this is in the 
templating code. That code is admittedly quite fragile. It is exposed a 
little but I doubt anything that I didn't write is using it so it seems 
quite possible to make it internal-only again. Therefore it should be safe 
to make changes there.

> There is use of hasOwnroperty on a host object.  The problem with that
> is there may be some sort of special [[Get]] for that object so even
> Object.prototype is in that object's prototype it will fail.

I don't think special [[Get]] is relevant here. Any object could shadow 
hasOwnProperty somehow. Of course it seems insane to design an API in 
javascript that does this, and it doesn't seem like you should ever *have* 
to do this for testing. However it could be fixed by changing all the 
o.hasOwnProperty(prop) to Object.prototype.hasOwnProperty.call(o, prop). 
That is bad for readability though, so I would like an example of 
something that will break if I don't make the change.

> anyone making assertions such as `assert(NaN, myvar)`, which the
> harness accounts for, is making unreasonable expectations. The test
> harness handles that misexpectation with:

I fail to understand what is unreasonable about that.

In general, I would prefer feedback in the form of specific comments about 
the testharness code or, better yet, example patches. I think it is much 
easier to reason about real examples than hypotheticals.

Received on Thursday, 7 April 2011 20:56:31 UTC