Menu
▾
▴
xpipe-developers
|
From: Michael C. <mic...@pr...> - 2002-07-24 13:15:15
|
According to the specification for XComponents, it can have multiple = UnitTests associated with it. This obviously enables an Xcomponent to be = tested by the XPipe engine before running it as a transformation stage = in an Xpipe. A Unit Test, by definition has pre and post conditions. The = XComponent itself has pre and post conditions also. Is it not overkill, = for a unit test to have pre and post conditions ??=20 Your thoughts please. |
|
From: Sean M. <sea...@pr...> - 2002-07-24 13:27:53
|
At 14:15 24/07/2002 +0100, Michael Coughlan wrote: >According to the specification for XComponents, it can have multiple >UnitTests associated with it. This obviously enables an Xcomponent to be >tested by the XPipe engine before running it as a transformation stage in >an Xpipe. A Unit Test, by definition has pre and post conditions. The >XComponent itself has pre and post conditions also. Is it not overkill, >for a unit test to have pre and post conditions ?? > >Your thoughts please. > The idea of the pre-condition on a unit test is to allow you to test something known to be a pre-requisite to executing the test case. For example, an XComponent unit test that will connect to JDBC source FOO can only be executed if FOO exists. The idea of the post-condition on a unit test is to allow you to test for desired side-effects of executing an XComponent. For example, if an XComponent creates a copy of its input file on a WebDav server somewhere, the post-condition could be a test to ensure the file has been written to the WebDav server sucessfully. Maybe this is making XComponents too clever? Sean |
|
From: David S. <ds...@st...> - 2002-07-24 14:02:30
|
I always imagined that the pre/post conditions for an XComponent or an XPipe were an implementation of programming by contract. It's like the same feature in languages like Eifel. These could be useful for ensuring that input is valid wrt some schema prior to processing, or that the output was valid subsequent to passing it on. Similarly it could be used to evaluate any finer grained constraint to ensure that the XComponent is only ever executed on input for which it is known to generate correct results. The pre/post conditions on tests serve a different purpose. These are the means to determine whether the test passed or failed. -----Original Message----- From: xpi...@li... [mailto:xpi...@li...]On Behalf Of Michael Coughlan Sent: Wednesday, July 24, 2002 9:15 AM To: xpi...@li... Subject: [Xpipe-developers] Pre and post Conditions in Unit Tests According to the specification for XComponents, it can have multiple UnitTests associated with it. This obviously enables an Xcomponent to be tested by the XPipe engine before running it as a transformation stage in an Xpipe. A Unit Test, by definition has pre and post conditions. The XComponent itself has pre and post conditions also. Is it not overkill, for a unit test to have pre and post conditions ?? Your thoughts please. |
|
From: Tony R. <ton...@pr...> - 2002-07-24 14:27:18
|
I agree on the pre/post conditions on the actual XComponent. When it
comes to unit tests though surely a unit test doesn't need to have a
pre/post condition on it. A unit test either is true or false. To me it
looks like there are too many levels of code around an actual XComponent
which strains the simplicity of the model. We could go on forever checking
the checks on the checks on the checks on the XComponents. Personally, I
think a line should be drawn at the unit tests as I don't think there should
be pre-conditions and post-conditions on unit tests...
T.
-----Original Message-----
From: xpi...@li...
[mailto:xpi...@li...]On Behalf Of David
Starr
Sent: 24 July 2002 15:03
To: Michael Coughlan; xpi...@li...
Subject: RE: [Xpipe-developers] Pre and post Conditions in Unit Tests
I always imagined that the pre/post conditions for an XComponent or an
XPipe were an implementation of programming by contract. It's like the same
feature in languages like Eifel. These could be useful for ensuring that
input is valid wrt some schema prior to processing, or that the output was
valid subsequent to passing it on. Similarly it could be used to evaluate
any finer grained constraint to ensure that the XComponent is only ever
executed on input for which it is known to generate correct results.
The pre/post conditions on tests serve a different purpose. These are the
means to determine whether the test passed or failed.
-----Original Message-----
From: xpi...@li...
[mailto:xpi...@li...]On Behalf Of Michael
Coughlan
Sent: Wednesday, July 24, 2002 9:15 AM
To: xpi...@li...
Subject: [Xpipe-developers] Pre and post Conditions in Unit Tests
According to the specification for XComponents, it can have multiple
UnitTests associated with it. This obviously enables an Xcomponent to be
tested by the XPipe engine before running it as a transformation stage in an
Xpipe. A Unit Test, by definition has pre and post conditions. The
XComponent itself has pre and post conditions also. Is it not overkill, for
a unit test to have pre and post conditions ??
Your thoughts please.
|
|
From: <de...@ei...> - 2002-07-24 16:07:31
|
All you really need by way of pre and post for unit tests is setup and
teardown; that way you don't have to manage the order the tests run in.
Bill
-----Original Message-----
From: xpi...@li...
[mailto:xpi...@li...] On Behalf Of Tony
Redmond
Sent: 24 July 2002 15:24
To: xpi...@li...
Subject: RE: [Xpipe-developers] Pre and post Conditions in Unit Tests
I agree on the pre/post conditions on the actual XComponent. When it
comes to unit tests though surely a unit test doesn't need to have a
pre/post condition on it. A unit test either is true or false. To me it
looks like there are too many levels of code around an actual XComponent
which strains the simplicity of the model. We could go on forever
checking the checks on the checks on the checks on the XComponents.
Personally, I think a line should be drawn at the unit tests as I don't
think there should be pre-conditions and post-conditions on unit
tests...
T.
-----Original Message-----
From: xpi...@li...
[mailto:xpi...@li...]On Behalf Of David
Starr
Sent: 24 July 2002 15:03
To: Michael Coughlan; xpi...@li...
Subject: RE: [Xpipe-developers] Pre and post Conditions in Unit Tests
I always imagined that the pre/post conditions for an XComponent or an
XPipe were an implementation of programming by contract. It's like the
same feature in languages like Eifel. These could be useful for
ensuring that input is valid wrt some schema prior to processing, or
that the output was valid subsequent to passing it on. Similarly it
could be used to evaluate any finer grained constraint to ensure that
the XComponent is only ever executed on input for which it is known to
generate correct results.
The pre/post conditions on tests serve a different purpose. These are
the means to determine whether the test passed or failed.
-----Original Message-----
From: xpi...@li...
[mailto:xpi...@li...]On Behalf Of
Michael Coughlan
Sent: Wednesday, July 24, 2002 9:15 AM
To: xpi...@li...
Subject: [Xpipe-developers] Pre and post Conditions in Unit Tests
According to the specification for XComponents, it can have multiple
UnitTests associated with it. This obviously enables an Xcomponent to be
tested by the XPipe engine before running it as a transformation stage
in an Xpipe. A Unit Test, by definition has pre and post conditions. The
XComponent itself has pre and post conditions also. Is it not overkill,
for a unit test to have pre and post conditions ??
Your thoughts please.
|
Thanks for helping keep SourceForge clean.
X