
Hi, Here is my current plan on CDL test case development: By Nov 9 meeting: - design of XML representation of CDL tests By Nov 16 meeting: - an initial version of XML representation of CDL test cases - a JUnit implementation that handles the test XML - an initial set of test cases -- failure cases; success cases matched with expected resolution -- a single CDL document for each test; no lazy resolution By the end of Nov we will adress: - how to treat multiple CDL documents (i.e. how to treat references in import) - how to treat lazy resolution (i.e. how to represent partially resolved documents) Thanks, Jun

Jun Tatemura wrote:
Hi, Here is my current plan on CDL test case development:
By Nov 9 meeting: - design of XML representation of CDL tests
If you look in the CVS repository, there is the file (under xml/api/test-helper.xsd) which describes a simple schema for testing, in which you have a <tests> element containing multiple <test> entries, each with an id, and xsd:any inside it. This lets me do files with multiple tests inside them, like this one for the addFile request. <?xml version="1.0"?> <t:tests xmlns:t="http://www.gridforum.org/cddlm/test-helper/2005/02" xmlns:api="http://www.gridforum.org/cddlm/deployapi/2005/02" xmlns:cdl="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0" xmlns:cmp="http://www.gridforum.org/cddlm/components/2005/02"
<t:test name="addFileRequest"> <api:addFileRequest> <api:name>urn:numbers://46</api:name> <api:mimetype>application/x-ssh-key</api:mimetype> <api:schema>http</api:schema> <api:data> AAAAB3NzaC1yc2EAAAABIwAAAIEAwVmUkPzXdWEyJZ8nCR8GvdrDtO00RI4Z Bg3Gyviuz5IrWj2C6b2BdcKn+S/swDV1fiEFY4+ewYHUfmg+UKm2T8Lfksjn Hinks0GoVvkwy3bF48U5yVk1akAzR5YbSLJa6Naj8XS9681xVzWpbjxrV3KR QNWvEqI0MqRE34MzT4M= </api:data> <api:metadata> <x:expires date="2005-07-18" xmlns:x="http://example.org/expiry" /> </api:metadata> </api:addFileRequest> </t:test> <t:test name="addFileResponse"> <api:addFileResponse> <api:item>http://server/job5/files/1</api:item> </api:addFileResponse> </t:test> </t:tests> I am currently just using this primarily to verify the API XSD matches my expectations of valid and invalid requests/responses. Actually, I lie. I have used it in one place to do in-process dispatch of data to an operation processor, then converted the response back to a XmlBeans CreateResponse wrapper and validating that. public void NotestDispatch() throws Exception { OMElement request=loadTestOMElement(DOC_CREATE, TEST_CREATE_REQUEST_HOSTNAME); CreateProcessor createProcessor = new CreateProcessor(portal); OMElement response = createProcessor.process(request); Axis2Beans<CreateResponseDocument> responseBinder = new Axis2Beans<CreateResponseDocument>(); CreateResponseDocument responseDoc=responseBinder.convert(response); assertValid(responseDoc); } Stuart and Alya's proposal for just in and out docs would let us have a testcase like <t:test id-="uuid:d90909009" t:status="approved" t:category="cdl:resolution"> <t:metadata> </t:metadata> <t:in> <cdl:cdl> ... </cdl:cdl> </t:in> <t:out> <cdl:cdl> ... </cdl:cdl> </t:out> </t:test> For failing tests it would be by changing the default value of the t:failing attribute, t:out would be optional. <t:test id-="uuid:d90909009" t:status="approved" t:category="resolution" t:failing="true" > I know status and category are the kind of metadata that goes into the metadata tag, but doing on attribute lets you select all tests in the resolution category using xpath, and I dont want to require the word ontology in our test docs. t:test[@t:category="cdl:resolution"] NB, although we can have >1 test under tests, I think all test docs ought to to have one test per doc, and give the doc the name name/number as its unique ID. Which would also imply we should not use uuids or other uris, but a simpler string like cddlm-cdl-2005-03-09-1; deploy api would be cddlm-api-2005-09-01-2, etc. we could use date+counter or simple counter per-category. for all our tests. -Steve <xsd:schema targetNamespace="http://www.gridforum.org/cddlm/test-helper/2005/02" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:t="http://www.gridforum.org/cddlm/test-helper/2005/02" elementFormDefault="qualified"> <!-- ============================================================= --> <xsd:annotation> <xsd:documentation> This is a schema to help test the CDL schemas. It allows you to list a set of arbitrary elements together in a long list. The aim is to make it easier to embed a set of XML elements into a single doc for faster and easier validation. </xsd:documentation> </xsd:annotation> <xsd:complexType name="testType"> <xsd:annotation> <xsd:documentation> XML to validate </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any namespace="##other"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional" /> <!--validity flag; useful in automated testing.--> <xsd:attribute name="valid" type="xsd:boolean" use="optional" default="true"/> </xsd:complexType> <xsd:complexType name="testsType"> <xsd:annotation> <xsd:documentation> multiple tests </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="test" type="t:testType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="test" type="t:testType"/> <xsd:element name="tests" type="t:testsType"/> </xsd:schema>
participants (2)
-
Jun Tatemura
-
Steve Loughran