On Tue, May 25, 2004 at 07:58:21PM +0200, Francisco Olarte Sanz. wrote: > 1st of all, thanks everyone for the prompt response regarding my > previous question about return values. > > Now a style question. I'm doing a database oriented module, and I have > rouhly the following tests: > > 1.- Test wether module can load ( just a require inside an eval ). > 2.- Test a bunch of functions for string processing (escaping) etc.. > which don't need server connections. > 3.- Test connection to the database. > 4.- Create a test database, connect to it > 5.- Create test tables, populate them, testing insertion functions on > the way. > 6.- Lots of tests which need the test database. > 7.- drop test database. > > I have 1 in a file, 2 split in several. 3 can be put in it's own file, > but the problems arrive with steps 4-7. Steps 5 and 6 are lengthy, and > I'd like to split them into several files, giving files 4, 5a, 5b, 5c, > 6a, 6b, 6c..6z, 7 but in this case steps 4-7 should be run to > completion. This goes against the recomendation of having tests which > can be run separately ( and takes slightly longer as i need to > reconnect on each test, but tests don't need to be so efficient). So > I'm now putting 4- in a single file, but it's becoming huge ( hundreds > of tests ). My question is.. > ¿ Which aproach is better, have a single independent huge test file or > several interdependent smaller ones ( w/ notes in the readme stating > test dependence ) ?
In general, I prefer the convenience of independent tests, but I have also written tests which have an ordering where that makes more sense. But remember that tests are just programs. If they are unwieldy, bring standard software development techniques to bear. There is no reason not to include modules in your distribution which are only required as part of the test suite. Then again, I like Joshua Pritikin's parenthetical question in Test.pm, "Your test code should be simpler than the code it is testing, yes?". Hmmm. I'm not sure whether that will help you make a decision or not. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
