There are lots of things that can fail. The network, your network card, the database daemon among many other things. You shouldn't be testing those so why test whether DBI can do them? If your interfaces are correct, then the fault will lie elsewhere and is down to the user to fix. If the database daemon isn't running for whatever reason, why should that mean you have a failed install? If you are correctly testing that the functionality of your modules is correct, then you shouldn't have to worry about whether DBI can talk to a live database.
If you ever get involved with designing a large system, then testing the interfaces is all you can do. The GEC Telecommunications project for designing a System X telephone exchange, took 3 days to do an end to end run. If we had ever had to install it elsewhere, doing an install test like that would been laughed at. As such we tested what went in was processed correctly and what came out met the agreed expected output, both for garbage and accurate data. It meant we could run the regressions tests on small parts of the system that could be slotted in when bugs were fixed, and we knew it would work within the whole system, because the interfaces were correct.
--
Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/
| [reply] |
| [reply] |
