RE: [Xpipe-developers] I see the light or do I?

[<de...@ei...>]

> Tony Redmond
>
> OK, I think I have it - the key to understanding pre and post=20
> conditions is to separate the idea of developing an XPipe=20
> engine from an XPipe creation environment. If you wish to=20
> create a new XComponent, you will of course want to test that=20
> component based on certain inputs. This is fine. Therefore a=20
> unit test is executed on an individual separated XComponent.=20
> This means that for example in a 20-stage pipe, an individual=20
> component cannot be tested in the middle of a pipe. It=92s a=20
> proper unit test =96 not an error logging system.

Exactly. At a coarser grain, it's going to be useful to be able to write
a test for an entire XPipe or a sequence of XComponents. This goes back
to idea of being able to treat XPipes and XComponents as the same
syntactic 'stuff'; not only is it useful for composition, it aids
development (for those who want to write tests; in the java open source
world, JUnit is de facto).


> 	For example, a unit test may consist of a DTD=20
> that validates the input to a unit test and a DTD that=20
> validates the output of a unit test. The unit test itself=20
> calls the XComponent to which the unit test is attached.

It might be worth looking at Eric Van der Vlist's XSLTUnit for this,
given we're doing XML io: <http://xsltunit.org/>.


> 	The interface is more important here=20
> though because it must have a boolean return type =96 i.e.=20
> whether the post condition passed or failed. This is where=20
> implementations may differ but that's fine.

Maybe having pre and post events being fired off would be a nice to have
for pipe monitoring (we could model the event stream as a parallel XPipe
and thoroughly confuse ourselves... ;).

Bill