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

[Tony R. <ton...@pr...>]

OK, I think I have it - the key to understanding pre and post conditions =
is
to separate the idea of developing an XPipe engine from an XPipe creation
environment. If you wish to create a new XComponent, you will of course w=
ant
to test that component based on certain inputs. This is fine. Therefore a
unit test is executed on an individual separated XComponent. This means t=
hat
for example in a 20-stage pipe, an individual component cannot be tested =
in
the middle of a pipe. It=92s a proper unit test =96 not an error logging =
system.
	Also, the execution environment for the unit test is implied i.e. the
XComponent specification does not include code for the execution of the u=
nit
test - the environment handles it.
For example, a unit test may consist of a DTD that validates the input to=
 a
unit test and a DTD that validates the output of a unit test. The unit te=
st
itself calls the XComponent to which the unit test is attached. In such a
case, the unit test is considered true if the pre-condition DTD validates
the input, the unit test doesn=92t fail and the post-condition DTD valida=
tes
the output. If any one of these fail, the entire unit test fails. Any
environment that support XPipe unit test must be capable of calling the
XComponent implementation in question on it's own.
	Pre and Post Conditions are however capable of being Java Classes or Pyt=
hon
code. This means that any implementation of pre/post conditions from code
must support some form of interface (the same applies to actual XComponen=
ts
code). The interface is more important here though because it must have a
boolean return type =96 i.e. whether the post condition passed or failed.=
 This
is where implementations may differ but that's fine.


T.