[cddlm] CDL test cases plan

[Steve Loughran]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-helper.xsd
Url: http://www.ogf.org/pipermail/cddlm-wg/attachments/20051102/0057579b/attachment.asc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: api-add-file-inline.xml
Type: text/xml
Size: 1024 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/cddlm-wg/attachments/20051102/0057579b/attachment.bin