Re: Nearly there

comments inlined

>>
>> [dd] To get things straight, then, this would mean that we can use the
>> tests that are not that different between levels as level 1 tests?
>>
>
> [mb] Yes, the vast majority of the tests can also be used as level 1 
> tests
> for
> the HTML Module.  This still does not solve the issue of having HTML
> tests for core.
>
[dd] OK, which means we leave out HTML tests for Core but tests Core and 
HTML implementations. Is that good enough?

>>> [mb] I think Lofton Henderson wrote a test writer's manual for svg 
>>> that
>>> I remember being reasonable.  Maybe we can take some things from it.
>>> Here's the link...
>>>
>>>     http://www.w3.org/Graphics/SVG/Test/svgTest-manual.htm
>>>
>> [dd] I'm working with Lofton in the QA group, I'll see if there's an
>> easy transition from that document to our test suite family. I suspect
>> it takes an equal amount of time to write a new document for our
>> purposes, since we have a different approach. I'll look into it over 
>> the
>> next few days.
>>
>
> [mb] That may very well be true.  What would you like to see covered in
> this document?  I can see two possibilites -- how to take a portion of 
> the
> spec, identify what can be tested, and set about building tests for 
> it.  I
> could also envision a section on the steps that should be taken after a
> test is written in xml.
>
[dd] What I had in mind is your first option, as it's probably what is 
least evident. Your second option, I think, is covered in other 
documents (Process for submitting and Build for building/checking out 
and so forth) which should perhaps be in a separate document.

Main things to be taken up in the document would be:

1. Identify what is being tested
2. Describe expected results
3. Description of the tests for matrix purposes
4. How we deal with programmatic constructs in DOM TS ML

> Any thoughts?
>
> --Mary
>
>> /Dimitris
>>
>>
>

Received on Wednesday, 9 January 2002 12:38:53 UTC