Re: Unit testing

Neil Conway <neilc@samurai.com> writes:

> Andrew Dunstan wrote:
> > 2. Won't dissolving away "static" cause naming conflicts?
> 
> It might, yes. Those can be resolved, I think. I don't see a good reason why
> function names can't be unique across the source tree; at the very least, it
> means less irritation for anyone using tags.

You can just compile all the objects normally, and compile the one object
you're going to test with static #defined away.

But it seems to me that most of the really hard bugs to find involve subtle
interactions between functions and the state of the database.

You wouldn't be able to find errors in the semantics of xids for example, or
in the WAL logic that didn't cover some corner case. Or race conditions
between backends...

Unit testing, especially at the level of detail of functions, is a mostly
bankrupt idea. It tests the very things that are easiest to track down. Where
it can come in handy is if you have entire modules with well defined external
interfaces, like the storage manager for example, then you can test them very
thoroughly -- possibly included scenarios that don't even come up in postgres.

But the storage manager is a bad example since it's pretty solid and doesn't
change much. I'm not sure transaction id management or management of locks and
so on are really well defined modules at a high enough level to be testing
anything significant.

-- 
greg