2002/ws/desc/test-suite TestSuiteContents.html,NONE,1.1

Update of /sources/public/2002/ws/desc/test-suite
In directory hutz:/tmp/cvs-serv31654

Added Files:
	TestSuiteContents.html 
Log Message:
Created Test Suite Contents document.

--- NEW FILE: TestSuiteContents.html ---
<html>
<head>
<title>Test Suite Contents</title>
</head>
<body>
<h1>Test Suite Contents</h1>

<address>Arthur Ryman</address>
<address>2004-11-11</address>

<h2>Introduction</h2>

<p>
Here are some initial thoughts on what we can test. Please 
comment. This document is based on
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html">Suggested Contents of Test Suite</a>.
</p>

<h2>CVS</h2>

<p>
The Test Suite is stored in CVS under the <a hef="http://dev.w3.org/cvsweb/2002/ws/desc/test-suite/">test-suite</a> module.
It contains the following test case folders which are described below:
<ul>
<li>documents - WSDL and XSD documents</li>
<li>messages - Web service messages</li>
<li>exchanges - Web service message exchanges</li>
</ul>
</ul>

<h2>Documents</h2>

<p>
WSDL is a language so we can test whether a document belongs to the 
language or not (actually, we need to apply this to a collection of 
documents since we have <import> and <include>). We can encode many, but 
not all of the language rules in XML Schema. The XML Schema is a normative 
part of the WSDL spec. However, there are rules that cannot be expressed 
in XML Schema and we need to record them. We will mine the WSDL spec and 
create a Test Assertion Document (TAD). Each assertion will be given a 
unique, stable, identifier.
</p>

<p>
Our test suite should consist of two buckets: Good and Bad (I am avoiding 
the use of the term Valid since XML already uses that term to indicate 
compliance with a schema).
</p>

<p>
The Good bucket consists of documents that are in the language. We should 
aim for adequate test coverage since people will look to this bucket for 
examples of usage of the capabilities of WSDL. I suggest we approach the 
test coverage problem as follows. We should analyse the XML Schema and 
extract a list of every element name, attribute name, and enumerated 
value, and we should aim that each appears in at least one Good test case.
</p>

<p>
The Bad bucket consists of documents that are not in the language. I 
suggest that our test coverage aims to have each Test Assertion be 
violated by at least one test case in the Bad bucket.
</p>

<h2>Messages</h2>

<p>
The above WSDL document tests address the syntax of the language. The 
semantics of the WSDL language include descriptions of messages. The WSDL 
specification includes binding rules that define the content of concrete 
messages as they are transmitted over some transport protocol, e.g. SOAP 
over HTTP. 
</p>

<p>
Our test suite should include buckets of Good and Bad message instances 
for each normative binding. Each test case in these buckets consists of a 
triple that contains a Good WSDL document, a message definition for some 
bound operation defined in the document, and a message instance. The test 
case is Good if the WSDL document correctly describes the message 
instance, and is Bad otherwise.
</p>

<p>
We need to mine the WSDL binding specs and extract a TAD for each binding. 
In the case where the message body is XML, there may be an XML Schema 
which can be used to validate the message, and we should add this to the 
test case.
</p>

<p>
The Good bucket should contain test cases that illustrate the use of each 
main aspect of the binding. The Bad bucket should contains test cases that 
in total violate each Test Assertion.
</p>

<h2>Exchanges</h2>

<p>
The WSDL spec also defines Message Exchange Patterns (MEP) that define an 
interaction with the Web service. This is part of the semantics of WSDL. A 
test case consists of a triple that contains a Good WSDL document, a bound 
operation defined in the document, and a set of message instances and 
their roles as defined by the MEP of the operation. A test case is Good if 
the message instances conform to the operation, and is Bad otherwise.
</p>

<p>
We need to mine the WSDL MEP spec and extract a TAD.
</p>

<p>
Our suite should contain Good test cases for each normative MEP and Bad 
test cases that in total violate each Test Assertion for each MEP.
</p>

<h2>Processor Behaviours</h2>

<p>
This area needs further clarification in the spec. We need to mine the 
spec and extract a TAD. 
</p>

<p>
A test case consists of a pair that contains a Good WSDL document, and 
some parameterization of the capabilities of a processor. This 
parameterization remains to be determined, but could consist of a list of 
"understood" namespaces, or an assertion that all namespaces are 
understood.
</p>

<p>
The Good bucket should contain WSDL documents that illustrate the major 
ways that extensions and be added to documents and be marked with 
wsdl:required. The Bad bucket should contain test cases that in total 
violate each Test Assertion.
</p>

</body>
</html>

Received on Thursday, 11 November 2004 17:02:29 UTC