Lists Home |
Date Index |
Paul Tucker wrote:-
>From what you have said, I see the need for at least three levels of
> when it comes to XML. I need to check that the document is valid in the
> XML sense (ie conforms to the DTD). I then need to check the data
>contained within any reply to my XML request is as expected. Finally I need
> to check that the application has done what it was supposed to do when
>the request arrived.
>With this in mind I need to run a series of positive and negative test
>using combinations of well formed documents, malformed documents,
>good data and bad data. With each request I need to perform the various
>checks that apply to that case (ie - does the document conform, if it does
>is the data OK and has the application done what it was supposed to do?).
>I'm now starting to get a picture of what I need to do (as above). Is this
>kind of testing that other people do or is it unique to my case?
With the exception of checking that your application has done the right
thing, the process you describe is very much how the OASIS/NIST XML
conformance tests  work.
The OASIS conformance test suite is comprised of a large number of of XML
input files with negative and positive tests. The positive tests have an
associated xml document which is the canonical form of the input document.
The XML parser under test is required to emit a canonical form of the input
document. This canonical output can then be compared with the expected
output. As canonicalization specifies a precise format, regular file
comparison tools can be used to check for equality.
To help automate the whole process, the XML input files are described by
another XML document which describes the intended purpose and outcome of