|
From: Tony R. <ton...@pr...> - 2002-07-30 10:31:10
|
Over the last few days I've spent a bit of time trying to get my head around the unit tests structure. Being interested in the complexity of having an xcomponent with pre/post conditions and then having a whole series of unit tests around the xcomponent with pre/post conditions and then having pre/post conditions around the unit tests, I was left feeling that the model is either over-complicated or maybe we just need some documentation to explain the unit test concept. It would appear that unit tests are used for run-time debugging and need to be able to be turned off. To me if they are not off by default in an XPipe engine, then it's going to be a very slow execution (time doing transform vs all the stuff around transform). Next, if they are turned on, are they all turned on? or can just one be turned on? or can just one unit test for one XComponent be turned on? On a more philosophical point - does it not seem overkill to have unit tests with pre/post conditions? You could argue that if the unit test is going to access a database for example that the existence of a database should exist before you run the test (and hence a pre-condition). However, if you write a Java class that does the unit test then the code to access the database has to be in the unit test code. Personally, I'm always going to check if a database exists at the point that I want to gain access to the database - not in another piece of code. Therefore I'd argue that the pre/post conditions for unit tests is overkill. Unit tests to aid the debugging process is fine but to do tests on the unit test that test the XComponents seems to be overkill. I'm sure I'm missing something here but I'd like someone to explain it to me... T. |