cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating Transformer)
Date Sun, 09 Jun 2002 01:08:27 GMT

Ovidiu,

I think I have answered my question about step composition.
Since Anteater is an Ant extenstion, the method used by WebTest (and Latka)
is applicable here.

We can just use external XML Entities to reference test steps.
Although not the most elegant mechanism, it is simple and works.

See here for example:
http://webtest.canoo.com/webtest/samples/ffo/NatPerSingle/MostSimple.xml


I am still waiting for response on the validation syntax and JUnit report
feed.



Ivelin


----- Original Message -----
From: "Ivelin Ivanov" <ivelin@apache.org>
To: "Ovidiu Predescu" <ovidiu@apache.org>;
<aft-devel@lists.sourceforge.net>; <cocoon-dev@xml.apache.org>
Sent: Friday, June 07, 2002 11:48 PM
Subject: Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating
Transformer)


>
> I will be interested to contribute some code.
> The validator package is totally independent of Avalon.
> It only needs commons-jxpath.jar
>
> The package is org.apache.cocoon.components.validation
>
> I guess I can just zip up the files in the package for anteater.
>
> I would like us to work out the exact syntax before starting, though.
>
> How do we plan to generate junit reports.
> Right now I don't see a nice way to interrupt a test, if there was a
> validation error, and jump straight to the junit reporting.
>
> I have also asked a question about reusing steps among test cases.
> How do you suggest this can be done?
>
> Once we work out the architectural problems, I'll move to coding.
>
> My sf.net login is "ivelin"
>
>
>
>
> Ivelin
>
>
>
> ----- Original Message -----
> From: "Ovidiu Predescu" <ovidiu@apache.org>
> To: "Ivelin Ivanov" <ivelin@apache.org>;
<aft-devel@lists.sourceforge.net>;
> <cocoon-dev@xml.apache.org>
> Sent: Friday, June 07, 2002 10:18 PM
> Subject: Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating
> Transformer)
>
>
> > Ivelin,
> >
> > This sounds very interesting, are you interested in adding this feature
to
> > Anteater and writing some documentation for it? If you're interested, I
> can
> > make you a committer to the project, so you can develop more easily.
Just
> > let me know your SourceForge account.
> >
> > The way I'd see this added is through an additional package in CVS. As
I'm
> > not familiar with the internals of the validator, I can't comment much
on
> > how this can be integrated. Is the validator implemented as a component
> > using Avalon? If so you'd need to change it to match the Ant style of
> > writing extensions. If exactly the same code from Cocoon can be reused
> > unmodified in Anteater, then perhaps the best option is to build a jar
> file
> > in Cocoon, and just drop it in Anteater's lib/ directory.
> >
> > Cheers,
> > Ovidiu
> >
> > On 6/7/02 4:51 PM, "Ivelin Ivanov" <ivelin@apache.org> wrote:
> >
> > >
> > >
> > > =================================
> > > ||     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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message