Test collection as part of group 2 efforts on Section 4

Here are some test cases that came out of group 2 efforts at the F2F. These
tests are for Section 4 of the spec, for some of the assertions noted in
Hugo's test collection document [1]. 

Some observations.

*	It seems many testable assertions in this part of the specification
needs to be tested by writing some echo kind of service. When someone needs
to write a echo service to verify conformance it becomes a little blurry as
it is really only testing the implementation of the service rather than
testing the SOAP implementation that is behind the service, which is
actually the goal of all these tests. 

*	Since Section 4 deals with the structure of the SOAP envelope, most
of the tests end up as testing whether the SOAP implementation understands
the SOAP structure and SOAP specified attributes etc. For example, just
testing whether server understands the existence of mustUnderstand, actor
attributes, encoding style etc. Since, the tests coming out of other
sections will test the semantics(processing model, data model etc) provided
by these attributes, lot of these tests may end up as duplicates (testing
the same thing). However, it is possible that some of these tests can be
considered as a kind of unit tests that tests the basic treatment and then
we progress to major (semantic processing)tests.

Here are the assertions and tests for those assertions. The assertions carry
the same index number as specified in [1].

o, Assertion A 9.1:

Text from the specification
	The encodingStyle attribute information item is a whitespace
delimited list where each item in the list is of type anyURI in the
namespace http://www.w3.org/2001/XMLSchema. 

This is changed to a single value now as per the recent decisions.

Test 

  Goal is to test whether the server understands the presence of
encodingStyle attribute in SOAP namespace.

   Send a simple SOAP message with an encodingStyle attribute in SOAP
namespace. Expect the service to echo the namespace and the value of the
encoding style sent. Success is indicated by a clean match with the values
sent.

   Send another message with a local name of encodingStyle in a different
namespace other than the SOAP namespace. Expect to get back empty values for
namespace and empty value for the encoding style.

o, Assertion 9.2 

Text from the specification
	all URIs syntactically beginning with
"http://www.w3.org/2001/09/soap-encoding" indicate conformance with the SOAP
encoding rules defined in [1](SOAP Encoding), though with potentially
tighter rules added.
Test

Check for understanding of SOAP defined encoding value.

   This probably will be tested in part II. Here just check whether the SOAP
node understands soap encoding style. Write a echo service that echoes back
the value of encoding style attribute only if it is a SOAP encoding style.
Send 2 messages; one with SOAP encoding style and one some other arbitrary
URI. Success is indicated by a valid return value which is empty for an
arbitrary URI and valid SOAP encoding URI for the message that contained
SOAP encoding style URI.

A more correct test will be to verify that the node makes use of that value
and does de-serialization accordingly. But, that is to be tested by part II
tests.

o, Assertion 9.3 
Text from the specification
	A value of the zero-length URI ("") explicitly indicates that no
claims are made for the encoding style of contained elements. This can be
used to turn off any claims from containing elements.

Test 1:
   Test for acceptance of empty encoding style attribute.

   Send a message with encoding style attribute set to empty string.

   No fault should be returned. Expect empty encoding style to be echoed
back.

Test 2:
   
Check scoping rules work correctly for encoding style. 

   Send a message with 3 nested elements with only the top element defining
a encoding style. Ask for the encoding style of the middle element. It
should be the same as set for the top element.

   Send a message with 3 nested elements each with different encoding style.
Outer one in SOAP encoding style,  the middle one with empty value for
encoding style and the last one SOAP again. Ask for the encoding style value
of the middle element. It should be empty. 

    Send a message with 3 nested elements each with different encoding
style. Outer one in SOAP encoding style,  the middle one with empty value
for encoding style and the last one SOAP again. Ask for the encoding style
value of the inner most element. It should be the same as the one specified
for inner-most element. 

o, Assertion A10.

   Test already exists in the test collection document [1]. Just add to the
existing comment that the fault code must be version mismatch fault

o, Assertion A11 

Text from the specification
	The Header element information item has:
*	A local name of Header 
*	A namespace name of http://www.w3.org/2001/09/soap-envelope 
*	Zero or more namespace qualified attribute information item
children.
*	Zero or more namespace qualified element information item children.
	All child element information items of the SOAP Header are called
SOAP header blocks.
	Each SOAP header block element information item:
*	MUST be namespace qualified;
*	MAY have an encodingStyle attribute information item
*	MAY have an actor attribute information item
*	MAY have a mustUnderstand attribute information item

Tests

o, Send a message with a proper header element and with one header block
whose element name is not namespace qualified. Expect a fault back. What is
the fault code ( check the spec )

o, Send a message with header element defined under different namespace
other than the SOAP namespace. Expect a fault back. (what is the fault code?
to expect)

o, Send a message with a proper header element with attributes for header.
If the request succeeds without any fault, then it indicates that the node
can live with the attributes on header element. Other variation of this test
case be, write a echo service that echoes back the attributes.

Testing mustUnderstand/actor and other SOAP defined attributes.

   The handling of these attributes by the SOAP server is probably going to
be tested through process/behavioral testing and in the case of encoding
through part II testing. So, what ever we do here as part of this assertion
will probably end up as overlaps at the least. Forgetting that, we can
define some unit tests to check whether the server provides special
treatment or understands them as soap defined attributes.

o, Expect a echo service that echoes back all SOAP defined attributes in a
message with the Qname of the attribute sent, the namespace the attribute is
associated with and the value specified in the message for that attribute.

    Send many messages each containing all or nothing or some combinations
of SOAP defined attributes. Expect the response message to contain the SOAP
defined attributes sent in the request.

Murali

References:

[1] http://www.w3.org/2000/xp/Group/1/09/ts-20011116.html

Received on Friday, 7 December 2001 17:01:21 UTC