Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F79BD27.3020308@mm.st>
Date: Tue, 30 Sep 2003 10:28:07 -0700
From: Steve K <shooz@mm.st>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.5b) Gecko/20030903 Thunderbird/0.2
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Unit testing pipelines?
References: <2A3CDA39-EF43-11D7-AD24-000393D2CB02@apache.org>
 <Pine.LNX.4.53.0309281944260.25463@lapgp.otego.com>
 <3F773DA9.7000503@virbus.de>
 <Pine.LNX.4.53.0309282244060.25463@lapgp.otego.com>
 <3F7758E3.8080109@virbus.de> <3F777DEC.3020701@mm.st>
 <3F77C91E.4020309@upaya.co.uk> <3F787128.4050804@mm.st>
 <3F787BA3.9040001@upaya.co.uk> <3F788268.7070200@mm.st>
 <3F789F07.4080005@upaya.co.uk>
In-Reply-To: <3F789F07.4080005@upaya.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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