OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Testing XML don't use xUnit

I think Michael and others are getting a little sidetracked with the science: like George the Animal Steele being distracted by the turnbuckle:  what ultimately really matters for Testing and QA is not raw pass/fail capabilities but the ability to efficiently determine what the defect is that caused the failure: for triage. That two languages may be equivalent in when they fail does not mean they are equivalent in how well they can help explain the failure or anomoly.

It would be reductionist to say that because C++ and Assembler are equally powerful, they are as workable or effective or substitutable for each other.

Yes Schematron does have contexts to allow multiple assertions from a single point, and yes it has sch:let  and sch :phase etc but the most important thing is that it almost forces the writer to make clear natural language statements with dynamic details: it moves the emphasis from "how can i express this constraint in Xpaths" to "how can i express this constraint in a way that lets the user grok the defect rather than the failure occurrence?"

We need to know which tables failed not just that some tables failed. Usually.

(One reason people like to validate with a progming language is that they can explore the failure with the same tool that detected it. This is an advantage that I think Schematron has. )

For the last few years most of my time has been spent on running really big comprehensive tests in Schematron on really big document sets. The raw pass/fail statistics are useful at the start and the end of testing, but  not for triage: this was a lesson I learned when I did write some Schematron patterns based on raw counts in context  / -- knowing there is a needle in the haystack does not get you very far: indeed we had a big delay because of it.

All languages embody an underlying "theory" of psychology: how people go about solving problems. I think Schematron's "theory" is holding up well after 13 years: compare Schematron assertions and patterns with Xsd assertions and types. Xsd supports no distinction between failures (markup domain) and defects (semantic domain). The failure may be at table/row[2]/entry[3]  but the defect may better expressed  "column three".

(There are now a rich variety of Xpath -using languages for testing. Some are organized as singleton "test cases" that may fit into some tool chains or test methodologies better than Schematron. I dont think that alters Schematron's particular strengths however. )


On Apr 11, 2013 4:59 AM, "Michael Kay" <mike@saxonica.com> wrote:
> Right. But XMLUnit doesn't let you do that because it requires an
> absolute path (thank you John) to the node you are testing.

I think it's quite powerful enough to write assertions of the form

every $t in //table satisfies ($t/thead and $t/tfoot)

and assertions like that are quite powerful enough to meet any unit testing needs that I've ever seen

Perhaps you're still thinking of the limitations of XPath 1.0?

Michael Kay


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS