From: mark p. <mar...@ed...> - 2002-11-24 23:29:56
|
On Sat, 23 Nov 2002 15:25:08 -0800 Kevin Goess's good news was: > > Mark, thanks for fixing that, but when I run 'make test' for version > 1.05 the test runs for at least 8 minutes before I get bored and kill > it. Looking at the test script, you don't actually seem to be testing > anything, you're just running it for a long time, all the files could be > ending up in /dev/null for all the test can tell. Might I be so bold as > to suggest > It is testing time based rotation. Which takes time not bytes to tickle. But you are right, it is boring and provides little feedback. > 1) If the test really needs to run for longer than about five seconds > then tell the user in advance how long the test is expected to take. > Nobody's going to want to run the test if it takes 10 minutes. But what > are you actually testing with all those iterations? > Time based rotation. I left the granularity up too high. > 2) To actually test the functionality, log enough bytes so that the > logfile rolls and then check the contents of "file.log" and > "file.log.1". You might take a look at the test I wrote to test the > interface to FileRotate, attached, and do something like that (although > Mike S. says he's seen it misbehave, so it might not be the best thing > to steal from). > I'll look at it. > 3) You should really test the file locking, there' enought code there > that it should be tested. This would involve refactoring the module so > that the test script can pause a logging operation right after it locks > the file and then launch another logging operation to see if it does the > right thing. > Once again I'll look into it. > 4) The test script sleeps for 180 seconds, so for 3 minutes + run time. > I gave up running it after about 8 minutes, so that would imply there's > some horrible runtime inefficiency going on? Could you check that out? > Hmm, ran it on my box and it took 3m0.639s. Not sure what you were seeing when you ran it. The sleep was so that I could run multiple "make test"'s from multiple xterms, so I could watch the time rotation and locking happening. Simple and crude but an effective way of watching what was going on. It is probably not what potential users want to see. I guess there needs to be a way of turning long running tests off or shortening them significantly - whilst making sure all aspects are being tested. The unfortunate issue is that there are branches in the code that will never get tested until someone wants a log rotated at greater than a yearly period. I guess I could trick time_to_rotate() into thinking it's time when it isn't really. > mark pfeiffer wrote: > > > > Oops ;-( typo! > > > ... snip ... cheers mark (who is not an idiot.... Just reeaaallllyyyyy sllooowwww :-) ) |