RE: [Xpipe-developers] Unit Tests

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

> Tony Redmond
>
> 	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.


A strawman split; pre and post conditions test running code is always in
a legal state; unit tests test the behaviour of code units for a given
state. Conditions are for helping the users, tests are for helping
developers. You want both; both are valuable, and we shouldn't let the
fact they both use asserts distract us. 

Let's use the DB example to distinguish them - In released code we would
like to have a pre condition that checks for a database connection and
have the condition do something appropriate when it fails. Similarly we
would like to do something sane on a rollback. But in development,
perhaps we don't need to connect to a db to run tests or develop code.
Once we know we can make a connection we should be able get on with
developing the code, preferably with a mock database connection - thus,
we unit test the code, not database connectivity. There's nothing worse
than stepping through a battery of failing tests fail only to find the
DB server is down, except not being able to develop without a live DB
connection in the first place. We can now see that there are
circumstances in development where we would like to turn off pre
conditions (especially those that are verifying the environment is as it
should be, as opposed to verifying the input is as it should be).
Moreover, in development we want to be able to test what happens when
the pre and post conditions are busted or even turned off. We can't
actually do that with the pre conditions themselves. We need tests.
While we don't run unit tests in a running XPipe system, we do want to
hand over the unit tests to a user, so they can run the tests on their
environment before sparking up (a form of regression testing). Again
that's not something we do straightforwardly with pre and post
conditions.


So perhaps rather than pre and post conditions, a unit test require a
setup phase. Since at some point you have to come out of the machine and
do an eyeball test, arguably we just inspect that the setup is ok. If we
find that bad setups keep breaking the tests, that's probably
information about the code, not our eyes. Personally I swear by the
xUnit frameworks for python and java; my experience with them is that
I've never needed to test a test, but I've often needed to eliminate
assumptions in my code about the environment, because that's what my
non-starter tests were telling me to do.

Here's an article by Steve Freeman about writing database code without a
database: <http://www.mockobjects.com/papers/jdbc_testfirst.html>

Bill