SV: [Xmlconf-developer] Updated domtest.xsd and simple attr.xml

Being the DOM WG representative and the first person to check tests that are
under invsetigation, I can only assure you that there will be tests on as
large a part of the different specifications as possible.

We haven't decided on a numeric test coverage. However, as far as level 3 is
concerned, we have agreed that it will be a complete _feature_ test suite,
pehaps not all of the spec, but enough to pinpoint severe funcionality
problems. (The reason for this is that it's very difficult to decide on a
number. 90 of what% the interfaces? interfaces+methods? and so forth)

Also, we welcome tests on every aspect of the specs, so I think that we
stand a good change of getting close to what you advocate. As soon as you
think we're off target, please write as many tests as you think appropriate.


/Dimitris

-----Ursprungligt meddelande-----
Från: David Brownell [mailto:david-b@pacbell.net]
Skickat: den 24 maj 2001 16:53
Till: Dimitris Dimitriadis
Kopia: www-dom-ts@w3.org
Ämne: Re: [Xmlconf-developer] Updated domtest.xsd and simple attr.xml


> We want to end up with a stable suite of tests over which there is as
little
> confusion as possible.

Do you have test coverage targets?   Such as to test 90% of the
DOM L2 spec?

One of my general concerns is that stability shouldn't take precedence
over being thorough ... it's easy to get stability by avoiding the parts
of the spec where implementors and specs diverge visibly.  That is,
by avoiding real trouble spots that turn up during testing!

I've got a strong preference to see those trouble spots get resolved, so
that applications won't trip over them.  It sounds like the process may
be more geared to avoiding such trouble spots than exploring/resolving
the differences that extensive testing will likely uncover.

- Dave

> So for example, a test expecting one outcome turns from
> a positive test to a negative test ... and a new test, with the
> "correct" outcome, is created.  For the original test, only the
> metadata changes ...

Received on Thursday, 24 May 2001 11:00:21 UTC