cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: [RT] Unit testing and CocoonUnit
Date Tue, 04 Nov 2003 09:41:28 GMT
Giacomo Pati wrote:

> Upayavira wrote:
>
>> Steve K wrote:
>>
>>> Upayavira --
>>> - Jakarta Cactus (http://jakarta.apache.org/cactus/) -- This takes a 
>>> similar approach by setting up a mock servlet environment to test 
>>> your servlets in.  However, it seemed way to big and complicated to 
>>> do what I thought would be very simple.  Also, I think there is a 
>>> lot to be gained by unit testing at the pipeline level as you 
>>> suggest, rather than treating Cocoon like just another servlet.
>>
>> I skimmed it too, but it didn't seem to fit.
>
> Have you guys also looked at Anteater http://aft.sf.net?
>
> My personal experience with HTTPUnit is that is somehow inflexible and 
> way too programmatic, not very declarative as Anteater is.

I've looked into Anteater now, and I'm starting to see how I could make 
a Cocoon unit test tool with it.

I do prefer the idea of a declarative (as opposed to programmatic) 
method for specifying tests, expecially given that a user who has never 
coded Java may want to establish tests for their site, and requiring 
Java to test a site that does not include any Java code of their own 
would be unfortunate.

I think I would extend Anteater to do something like this (extracted 
from the calc.xml Anteater test in CocoonCVS):

  <target name="calc">
    <property name="calc" value="${cocoon}/samples/flow/calc/"/>

      <cocoonRequest href="${calc}/"
           description="Test the 'calc' JavaScript implementation">

        <pipelineMatch stage="1">
          <xpath select="page/content/form/@method" value="post"/>
        </pipelineMatch>

        <pipelineMatch stage="last">
          <xpath select="html/body//form/@action" assign="cont1"/>
        </pipelineMatch>
      </cocoonRequest>

      </etc>
  </target>

With this, instead of an <httpRequest> you have a <cocoonRequest> which 
passes the request direct to Cocoon. Then, instead of a <match> you have 
a <pipelineMatch>, which chooses a particular stage from a pipeline. 
Stages can be reffered to by number, or with the keywords "last" or 
"penultimate".

With this, you can use the full range of test that are available to 
Anteater: xpath, regexp, contentEquals, etc.

With code like the following:

<cocoonRequest href="database.html">
  <pipelineStage stage="1" filename="esql-output.xml"/>
  <pipelineMatch stage="2">
    <xpath select="....."/>
  ...
</cocoonRequest>

The user can state that they want the output of stage 1 to be replaced 
with the contents of the file esql-output.xml. Imagine you're testing a 
site that is driven using an ESQL XSP page. To test this, you want a 
static XML, rather than having to actually access the database. Here, 
whilst the pipeline will still hit the database and the XSP will still 
generate XML, this generated XML will be ignored and the contents of 
eqsl-output.xml will be passed on to the next stage of the pipeline, 
creating a managable way to test a single stage in a pipeline.

The remainining unanswered question is how I could initialise a Cocoon 
instance (probably via a modified CocoonBean) at test startup, and then 
have that Cocoon available to all subsequent cocoonRequest objects. 
Anyone got any ideas about this?

Where the code for this goes, I'm not sure either. Is it part of 
Anteater, or a part of Cocoon? Or neither?

What do you all think? Is an Anteater approach better than a 
programmatic HTTPUnit one?

Regards, Upayavira



Mime
View raw message