shaping up Xproc unit test thoughts

shaping up some ideas on unit testing with xproc;

I would place under a different optional library...have scratched out
the following as a starting point for discussion;

<t:test-suite>

<t:test name="check-ex-pipeline" msg="checking pipeline output">
<p:input port="test-source">
  <p:pipe step="xform" port="result"/>
</p:input>
<p:input port="expected">
  <p:document href="test.xml"/>
</p:input>

<t:assert msg="checking result has title element">
</t:assert>

<t:assert msg="checking result has body element">
</t:assert>

<t:assert msg="checking result has meta tags">
</t:assert>

</t:test>

</t:test-suite>

now a few questions and thoughts;

*  I guess a  t:test type step could be considered very similar to p:viewport

* I would like to append output from multiple tests to a single
p:output, unsure of how this is achievable with current p:output
definition and allowed sequence

* I have left the t:assert elements empty for now, but one can imagine
assertions testing for true, false, xml-equals, xml-not-equals,
xpath-exists, xpath-not-exists, etc....not quite sure if its a
parameter or an option ...probably being silly here

* I see such unit tests as valuable part of documentation of code, so
I would advocate for them living inside p:pipeline

* should such tests be applied to steps, compound steps, pipelines and
subpipelines or should I make some differences now in the t:test
element

* anyone know of test result microformats  out there...over the years
I have seen a few come and go with no adoption. Junit xml output is
useful as a starting point

* test failure, what does it mean ...I know that when a test fails
this means it is indicated in the output

* must think a bit more about issues with context and inherited
environment with testing

* an implementation detail, switch to turn on or off understanding t:
namespace elements

any feedback welcome.

cheers, Jim Fuller

Received on Monday, 11 June 2007 22:10:15 UTC