You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jh...@virbus.de> on 2003/09/28 21:59:37 UTC
Re: [Vote] Build infrastructure
Giacomo Pati wrote:
> Well, as my time permits it and Berin could give a hand as well, why
> not.
>
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
> in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
IMO Ant is inflexible in general and adding flexibility (e.g. by using
parameterized antcall) slows down the build process.
> 2) Centipede
> in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
Can not evaluate it.
> 3) Maven
> ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it
Heard interesting things it (besides the opinion that there is nearly no
documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
necessary flexibility into Ant.
Joerg
Re: Unit testing pipelines?
Posted by Guido Casper <gc...@s-und-n.de>.
Steve K <sh...@mm.st> wrote:
> Guido --
>
>> What exactly led you to propose HTTPUnit but prevents you from using
>> Anteater for the very same purpose (just curious)?
>
> I'm sorry if I gave that impression. Correct me if I'm wrong, but I
> believe HTTPUnit and the anteater scripts both test in a similar way
> -- they simulate an http based user-agent, sending requests to the
> site, and then test the result HTML for correctness. I am looking to
> do testing on the pipeline level, before the data is transformed into
> HTML and sent to the user.
>
> I think I explained what I'm looking for a little better in my reply
> to Upayavira.
>
> Sorry for the confusion,
No reason to be sorry.
Thanks for the explanation.
Guido
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Guido --
> What exactly led you to propose HTTPUnit but prevents you from using
> Anteater for the very same purpose (just curious)?
I'm sorry if I gave that impression. Correct me if I'm wrong, but I
believe HTTPUnit and the anteater scripts both test in a similar way --
they simulate an http based user-agent, sending requests to the site,
and then test the result HTML for correctness. I am looking to do
testing on the pipeline level, before the data is transformed into HTML
and sent to the user.
I think I explained what I'm looking for a little better in my reply to
Upayavira.
Sorry for the confusion,
-steve
Re: Unit testing pipelines?
Posted by Guido Casper <gc...@s-und-n.de>.
Steve K <sh...@mm.st> wrote:
> Vadim --
>
>> Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It
>> can do some of that, and may be all of that you want, I don't know
>> all the capabilities of anteater.
>
> Thank you for pointing out the anteater stuff. It isn't exactly what
> I'm looking for, but will be handy for testing stuff higher up on the
> stack.
What exactly led you to propose HTTPUnit but prevents you from using
Anteater for the very same purpose (just curious)?
Guido
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Vadim --
> Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It can
> do some of that, and may be all of that you want, I don't know all the
> capabilities of anteater.
Thank you for pointing out the anteater stuff. It isn't exactly what
I'm looking for, but will be handy for testing stuff higher up on the stack.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
> Steve K wrote:
>
>> Hello everyone --
>>
>> I am currently building a Cocoon application and so far I've extended
>> the ExcaliburTestCase class to write my JUnit tests for the
>> components I'm creating. However, I'm now at the point where I am
>> starting to write pipelines that generate XML based on the database
>> manipulations the previously mentioned components perform, and it
>> appears that there is no easy way to test these. For example, my
>> ideal test code might look like:
>>
>> myCustomComponent.doSomething();
>> Document actualXml = cocoon.process("/path/to/my/pipeline");
>> Diff diff = new Diff(actualXml, expectedXml);
>> assertTrue("pipeline test", diff.identical());
>>
Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It can
do some of that, and may be all of that you want, I don't know all the
capabilities of anteater.
Vadim
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Upayavira wrote:
> "Putting test stuff in cocoon itself"? What do you mean?
In my experience writing tests, generally you regard the thing you are
testing as a "black box" -- the thing being tested should have no
knowledge that it is being tested rather than running in a production
environment. For example, the ExaclburTestCase is used to set up an
Avlon environment for you to test Avalon components without changing
them. I feel that adding "unittest" transformers to the sitemap or
using a custom pipeline processor violates this principle. However, I
am not overly religious about this -- if there already was a
UnitTestPipeline and the appropriate hooks into the CocoonBean I would
probably use it.
It seems to me that the closest thing to what I really want would be the
processURI() method in CocoonWrapper. Assuming this could be
instantiated and called from a JUnit test, it would give me the black
box effect I'm looking for. Ideally I'd like to be able to call any
pipeline (including internal-only ones) and get back the result XML
rather than the serialized form. I am not very familiar with the
internals of Cocoon, but I suspect this would not be an easy thing to
do. So we're probably back to a custom pipeline processor that can
gather the XML from each step of the pipeline and return it in the
environment somewhere (where would that be?).
It also might be possible to host the Cocoon component in the
EcaliburTestCase environment -- but I'm not sure if this gets me any
closer to the internal-only pipelines and XML as I'm still at the mercy
of the process() method.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> > Upayavira wrote:
>
>> I think the bit that Vadim didn't perhaps mention is that you could
>> use something like HTTPUnit with cocoon views, thus getting at the
>> content at a certain point in a pipeline. You could even build views
>> that have transformations to simplify this XML, so that when you get
>> XML out of your view, you can do an identity comparision with your
>> expected XML.
>
>
> That is a good use of the view, however I have this strong desire to
> have the testing of pipelines more integrated with my JUnit tests. I
> like being able to click the "run" button on Eclipse and watch the
> little green bar move across the screen without having to worry about
> starting up cocoon, etc. Also, my tests would be more like "do x with
> component a, and check the results of pipeline y" which would require
> putting test code within cocoon if I wanted to use anteater, etc.
>
>> The challenge would be how to link a particular XML that has been
>> 'intercepted' within a pipeline with an expected XML. How do you
>> 'annotate' a pipeline to identify what XMLs you're expecting?
>
>
> Hm... how about a custom pass-through transformer that will validate
> the xml against a document in the environment referenced by some id?
> something like:
What I was talking about was doing something like that transparently -
i.e. so you don't need to make changes in your sitemap.
> <map:generate src="sql.xml"/>
> <map:transform type="sql"/>
> <map:transform type="xmlunit">
> <map:parameter name="expected-xml-id" value="sqlresult"/>
> </map:transform>
> ...
>
> The "sqlresult" document would be placed in the environment by the
> test before the pipeline is called. And perhaps the xmlunit
> transformer could be part of a view made for testing.
That sounds sensible. Have the Bean add a 'something' to the
ObjectModel, which is then used by the UnitTransformer, which you've
placed into a view. The UnitTransformer then uses this object in some
way to evaluate whether or not the XML is valid. Then you can pass back
the result to the caller, either as XML, or using a text serializer.
This would be much simpler than a UnitTestingPipeline, but would have
the downside that each stage you test in a pipeline would require a page
to be generated, whereas with a UnitTestingPipeline, you could test all
stages in the pipeline in one go, but it would be much harder to configure.
> This might be easier than the custom pipeline processor, but I'm still
> not happy with putting test stuff in cocoon itself.
"Putting test stuff in cocoon itself"? What do you mean?
Regards, Upayavira
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
> Upayavira wrote:
> I think the bit that Vadim didn't perhaps mention is that you could use
> something like HTTPUnit with cocoon views, thus getting at the content
> at a certain point in a pipeline. You could even build views that have
> transformations to simplify this XML, so that when you get XML out of
> your view, you can do an identity comparision with your expected XML.
That is a good use of the view, however I have this strong desire to
have the testing of pipelines more integrated with my JUnit tests. I
like being able to click the "run" button on Eclipse and watch the
little green bar move across the screen without having to worry about
starting up cocoon, etc. Also, my tests would be more like "do x with
component a, and check the results of pipeline y" which would require
putting test code within cocoon if I wanted to use anteater, etc.
> The challenge would be how to link a particular XML that has been
> 'intercepted' within a pipeline with an expected XML. How do you
> 'annotate' a pipeline to identify what XMLs you're expecting?
Hm... how about a custom pass-through transformer that will validate the
xml against a document in the environment referenced by some id?
something like:
<map:generate src="sql.xml"/>
<map:transform type="sql"/>
<map:transform type="xmlunit">
<map:parameter name="expected-xml-id" value="sqlresult"/>
</map:transform>
...
The "sqlresult" document would be placed in the environment by the test
before the pipeline is called. And perhaps the xmlunit transformer
could be part of a view made for testing. This might be easier than the
custom pipeline processor, but I'm still not happy with putting test
stuff in cocoon itself.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> Upayavira --
>
>> So, a UnitTestingPipeline in combination with extensions to the
>> CLI/Bean to be able to configure this pipeline, wouldn't be too hard
>> to implement. Are you interested?
>
>
> That is an angle I had not considered -- it does provide a flexible
> way to test not only the end result, but also the intermediate steps
> of a pipeline. My only concern would be that using a different
> pipeline may taint the testing process as you wouldn't use the
> UnitTestingPipeline in a live application.
>
> When I was first thinking about this, I was imagining testing short
> internal-only pipelines -- the types of pipelines that would be
> aggregated in other pipelines. For example, just testing the result
> of a FileGenerator + SQLTransformer pipeline. In contrast, testing
> the result of complete pipelines seems best handled by existing tools
> such as HTTPUnit, Cactus, or the anteater scripts that Vadim pointed
> out to me.
I think the bit that Vadim didn't perhaps mention is that you could use
something like HTTPUnit with cocoon views, thus getting at the content
at a certain point in a pipeline. You could even build views that have
transformations to simplify this XML, so that when you get XML out of
your view, you can do an identity comparision with your expected XML.
That way you could do 'unit testing' of pipeline stages with a
functional testing tool such as HTTPUnit or Anteater, just using cocoon
views when generating the page.
> Since I'm still a few days away from actually writing pipelines for my
> application, it is hard for me to say which style of testing would be
> most useful. I plan on isolating all my logic in flow (that calls
> other components) and using the pipelines strictly for gathering xml
> and transforming it for display.
>
> Do you feel the CocoonBean could be modified to grab the output from
> the short, internal only type pipelines that I described?
The challenge would be how to link a particular XML that has been
'intercepted' within a pipeline with an expected XML. How do you
'annotate' a pipeline to identify what XMLs you're expecting? If you can
just say:
<generator-xml src="..."/>
<transformer-xml src=".../"/>
<transformer-xml src=".../"/>
<transformer-xml src=".../"/>
<serializer-xml src=".../"/>
It might work, but how would you deal with aggregation, etc. I suspect
that building the pipeline wouldn't be too hard, but working out how to
build the configuration side of things would be quite a challenge.
> I imagine I'd have to expose those internal pipelines to the outside
> somehow...
See above stuff on views.
> perhaps your solution would be the easiest.
Not sure. I'd try anteater and view first.
> Maybe when I reach the point where I need something I'll to cobble
> together a UnitTestingPipeline.
I'd be interested to see it if you do!
Regards, Upayavira
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Upayavira --
> So, a UnitTestingPipeline in combination with extensions to the CLI/Bean
> to be able to configure this pipeline, wouldn't be too hard to
> implement. Are you interested?
That is an angle I had not considered -- it does provide a flexible way
to test not only the end result, but also the intermediate steps of a
pipeline. My only concern would be that using a different pipeline may
taint the testing process as you wouldn't use the UnitTestingPipeline in
a live application.
When I was first thinking about this, I was imagining testing short
internal-only pipelines -- the types of pipelines that would be
aggregated in other pipelines. For example, just testing the result of
a FileGenerator + SQLTransformer pipeline. In contrast, testing the
result of complete pipelines seems best handled by existing tools such
as HTTPUnit, Cactus, or the anteater scripts that Vadim pointed out to me.
Since I'm still a few days away from actually writing pipelines for my
application, it is hard for me to say which style of testing would be
most useful. I plan on isolating all my logic in flow (that calls other
components) and using the pipelines strictly for gathering xml and
transforming it for display.
Do you feel the CocoonBean could be modified to grab the output from the
short, internal only type pipelines that I described? I imagine I'd
have to expose those internal pipelines to the outside somehow...
perhaps your solution would be the easiest. Maybe when I reach the
point where I need something I'll to cobble together a UnitTestingPipeline.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> Hello everyone --
>
> I am currently building a Cocoon application and so far I've extended
> the ExcaliburTestCase class to write my JUnit tests for the components
> I'm creating. However, I'm now at the point where I am starting to
> write pipelines that generate XML based on the database manipulations
> the previously mentioned components perform, and it appears that there
> is no easy way to test these. For example, my ideal test code might
> look like:
>
> myCustomComponent.doSomething();
> Document actualXml = cocoon.process("/path/to/my/pipeline");
> Diff diff = new Diff(actualXml, expectedXml);
> assertTrue("pipeline test", diff.identical());
>
> I suppose I could use something like HTTPUnit here, and set up a test
> script to start cocoon, request the uri and parse the result into
> XML... but that seems a little messier than it should be.
>
> I've looked at the CocoonBean stuff, and while it is close, it seems
> geared toward publishing pages rather than embedding cocoon and
> directly calling pipelines.
>
> Does this sound like a good idea, or is everyone just using HTTPUnit
> for this level of testing? Might it be possible to modify CocoonBean
> to allow direct access to the result of calling a pipeline? Does
> anyone think unit testing pipelines this way is actually valuable?
Steve,
The bean is intended to be a programmatic interface to Cocoon, not just
for publishing. There is a method (I'm not sure how well it works
though, but I can check), to write the contents of a pipeline to an
output stream, which is closer to what you are talking about.
You could do what you're talking about by implementing a
UnitTestingPipeline, to replace the default CachingProcessingPipeline.
So what you'd do is, in the Bean, pass in a set of 'expected' XMLs'. for
each stage of the pipeline. The Bean puts these details into the
environment, available for the pipeline. When generating a page, the
UnitTestingPipeline, as well as passing the content of the stage on to
the next stage, takes a copy and compares it to the relevant 'expected
XML' for that stage. If you look at AbstractCachingPointPipeline, I
think you'll see a pipeline that more or less does this, in order to
cache the content. You could replace that with code to test the XML.
So, a UnitTestingPipeline in combination with extensions to the CLI/Bean
to be able to configure this pipeline, wouldn't be too hard to
implement. Are you interested?
Regards, Upayavira
Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Hello everyone --
I am currently building a Cocoon application and so far I've extended
the ExcaliburTestCase class to write my JUnit tests for the components
I'm creating. However, I'm now at the point where I am starting to
write pipelines that generate XML based on the database manipulations
the previously mentioned components perform, and it appears that there
is no easy way to test these. For example, my ideal test code might
look like:
myCustomComponent.doSomething();
Document actualXml = cocoon.process("/path/to/my/pipeline");
Diff diff = new Diff(actualXml, expectedXml);
assertTrue("pipeline test", diff.identical());
I suppose I could use something like HTTPUnit here, and set up a test
script to start cocoon, request the uri and parse the result into XML...
but that seems a little messier than it should be.
I've looked at the CocoonBean stuff, and while it is close, it seems
geared toward publishing pages rather than embedding cocoon and directly
calling pipelines.
Does this sound like a good idea, or is everyone just using HTTPUnit for
this level of testing? Might it be possible to modify CocoonBean to
allow direct access to the result of calling a pipeline? Does anyone
think unit testing pipelines this way is actually valuable?
thanks for any advice,
-steve
Re: [Vote] Build infrastructure
Posted by Stephen McConnell <mc...@apache.org>.
Having been though the process of setting up Maven for several projects
- and during the process experienced the evolution form Maven 0.7 to the
current 0.10, I can confirm that Maven in its current form is usable and
functional.
There are bugs in the Maven 10 release, many of which have been resolved
under the imminent beta 11/RC1. There are also a number of defensive
practices that can be employed to minimise problems. There are several
examples of maven based builds in Avalon - the Framework 4.1.5 release,
the recently released Avalon Meta 1.1 package, a number of recently
converted Excalibur packages (i18n 1.1 and configuration and 1.1), and
the new Merlin 3.0 container release. These collectively represent a
total of more than 40 maven subprojects consolidated under 5 parent
project.
Stephen.
Joerg Heinicke wrote:
> Giacomo Pati wrote:
>
>>>
>>>> 3) Maven
>>>> ATM this is my preferred build infrastructure and I could help
>>>> building the 2.2 repo based on it
>>>
>>>
>>> Heard interesting things it (besides the opinion that there is
>>> nearly no
>>
>
> ^^^^^ ^^^^^^^
>
>>> documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
>>> necessary flexibility into Ant.
>>
>>
>>
>> What do you mean with 'there is nearly no documentation'? About Maven
>> itself? I've found the web site and other resources quite enough to
>> start using it for sever projects now. What do you miss?
>
>
> See above. I didn't have a look on it myself. It was about Maven and
> especially Jelly. And as far Maven uses Jelly ...
>
> Joerg
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: [Vote] Build infrastructure
Posted by Joerg Heinicke <jh...@virbus.de>.
Giacomo Pati wrote:
>>
>>>3) Maven
>>> ATM this is my preferred build infrastructure and I could help
>>> building the 2.2 repo based on it
>>
>>Heard interesting things it (besides the opinion that there is nearly no
^^^^^ ^^^^^^^
>>documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
>>necessary flexibility into Ant.
>
>
> What do you mean with 'there is nearly no documentation'? About Maven
> itself? I've found the web site and other resources quite enough to
> start using it for sever projects now. What do you miss?
See above. I didn't have a look on it myself. It was about Maven and
especially Jelly. And as far Maven uses Jelly ...
Joerg
Re: [Vote] Build infrastructure
Posted by Giacomo Pati <gi...@apache.org>.
On Sun, 28 Sep 2003, Joerg Heinicke wrote:
> Giacomo Pati wrote:
>
> > Well, as my time permits it and Berin could give a hand as well, why
> > not.
> >
> > But first we need to come to a consensus about which build
> > infrastructure we would support to use:
> >
> > 1) Ant
> > in this case we can use the current build system and tune it to the
> > needs we have for the 2.2 and maybe add some ruper task to get rid
> > of jars in our repository (suggested by Nicola Ken IIRC) and some
> > more for modularisation ease
>
> IMO Ant is inflexible in general and adding flexibility (e.g. by using
> parameterized antcall) slows down the build process.
>
> > 2) Centipede
> > in this case I could not volunteer as I'm out of Centipede since
> > their move from Cents to Antlibs (we still have some customer
> > project using a Cents based version of it but they will never move
> > to Antlibs)
>
> Can not evaluate it.
>
> > 3) Maven
> > ATM this is my preferred build infrastructure and I could help
> > building the 2.2 repo based on it
>
> Heard interesting things it (besides the opinion that there is nearly no
> documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
> necessary flexibility into Ant.
What do you mean with 'there is nearly no documentation'? About Maven
itself? I've found the web site and other resources quite enough to
start using it for sever projects now. What do you miss?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com