|
From: Tony R. <ton...@pr...> - 2002-07-30 16:18:41
|
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. |