=================================
|| VERY LONG !!! ||
=================================
|| AND INTERESTING. ||
=================================
I am surprised that there is not much interest in the Cocoon community for
Anteater. What do people use for web apps functional test suites?
There are a few other open source test tools, but I think Anteater has great
potential. Especially for Cocoon apps.
So, let's begin:
- 1 -
While Anteater is still not solidified and has a relatively small user base,
I would like to suggest an architectural change, which is compatible with
Anteater's values, but will hopefully
improve it in the following areas:
1) standartization
2) learning curve
3) cross project code reuse
4) maintainance
The ideas is to use references to schema documents of standard XML languages
(like Schematron, DTD, XML Schema, Relax NG) for response validation,
instead of supporting a proprietary grammar.
I suggest that we use the org.apache.cocoon.components.validation package
which is an independent component in Cocoon's main tree and is used by
XMLForm.
The Schematron implementation is already available and I think it is quite
suitable for Anteater, because Schematron is a superset of Anteater's match
element.
To be precise it is a superset of the validating use, i.e the cases when
match is used to assign value to a "result" property. Asigning values within
<match/> to other properties which are used for subsequent requests is a
separate concern.
- 2 -
Schematron was specificly designed for partial, multi-phase validation and
user friendly error reporting.
I'll explain how points 1-4 above are addressed by this proposal:
1) Schematron is relatively popular. There are a number of articles in
popular magazines which promote Schematron over other validating schemas.
2) Schematron is very easy to learn. Specification and tutorials are
availbel. There is also supporing discussion groups with decent response
time.
3) Schematron is used for a number of projects. For example there is a
complete RSS 1.0 validating schema available on the RSS site.
http://home.freeuk.com/leigh.dodds/rss_validator/
XMLForm is using schematron extensively as well. Slash-edit is another
example.
4) Maintainance of Schematron documents is easy. Minor local changes are
made as the underlying (validated) model changes.
- 3 -
5) Bonus ;)
Here is one additional reason why I posted this proposal.
Validating Schematron documents can be referenced in a transparent
transformer prior to a page serialization.
This can be useful in development and QA, to catch and report bugs in
content (HTML, WAP, XML, etc.) during navigation.
Searching for problems in a broken HTML page (or other xml markup) can be
painful.
Instead of searching for the missing tags or label or icon, the tester (or
developer) will see a meaningful error report in place of the actual page.
After testing certain pages time and again, the eye tends to ignore elements
peripheral to the currently tested feature.
If there is an underlying validating document which is applied before
display, then things may be easier. The developer (tester) has to only make
changes to it when the page structure changes.
The rest of the time this document will be a safeguard of unexpected
problems caused as side efects by the development of other features or bug
fixes or another one of the infinite other possible reasons.
The transformer applying the validating document can be, of course, turned
off in production.
Now the next interesting part. The forementioned validating documents can be
referenced just as well by Anteater regression suites as they can by a
pipeline embedded validating transformer.
- 4 -
As a quick thought, this is how an Anteater script may look:
<?xml version="1.0" encoding="utf-8"?>
<project name="calc-test" default="calc">
<!-- Simulate the behavior of a user that opens a browser, starts
the calculator example, and goes back in the processing several
times. -->
<target name="calc">
<property name="calc" value="${cocoon}/samples/flow/examples/calc/"/>
<property name="schema-doc-ns"
value="http://www.ascc.net/xml/schematron"/>
<property name="schema-doc-url"
value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
<http description="Test the 'calc' JavaScript implementation">
<httpRequest href="${calc}/">
<match>
<xpath select="html/body//form/@action" assign="cont1"/>
<validate phase="page1" assign="violations">
</match>
</httpRequest>
<echo>result = ${violations}</echo>
</http>
....
Then the Schematron document would be something like:
<schema xmlns="http://www.ascc.net/xml/schematron";>
<title>Schema for the Calc example</title>
<phase id="page1">
<p>first page check.</p>
<active pattern="form-present"/>
</phase>
... other phases ...
<pattern name="Test for HTML form element" id="form-present">
<rule context="/">
<assert test="//form">
Form element expected on this page.
</assert>
<assert test="//form/@action">
Form element must have action attribute.
</assert>
</rule>
... other rules ...
</pattern>
... other patterns...
</schema>
...
Where the validate element will use the validation package to apply the
schema against the document.
The violations can be then nicely integrated in the JUnit reporting package.
If there are enough votes I'll contribute some of the work myself.
Help would be certainly appreciated.
Thanks for reading this far.
Thoughts?
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
