On Sat, Apr 03, 2004 at 01:37:03AM +0200, Paul Johnson wrote: > Coming soon to Devel::Cover (well, on my TODO list anyway): > > - Provide an optimal test ordering as far as coverage is concerned - ie > tests which provide a large increase in coverage in a short time are > preferred. There should also be some override to say run these tests > first anyway because they test basic functionality.
For me, the "perfect" order of display would be: Coverage A is a subset of Coverage B implies that Test A must be displayed before Test B. You could call Test A a subtest of Test B. You then order all the tests by their coverage increase and attempt to display them in that order (while satisfying the above rule). This will ensure that low level precedes high level (because the low level tests will be subsets of the high level ones). You need to consider subset in terms of packages or modules rather than function, otherwise if lowlevel.t tests func1() and func2() but highlevel1.t only calls func1 then there is no subset relationship. You also need to keep your test scripts kind of modular . On the other hand, if you are trying to save time on your test suite then the same information as above can be used to cut corners. You run the tests in coverage increase order until you have run out of tests that will increase the coverage, then you stop. The only exception is if a Test C fails, then you run it's largest subtest (Test B) and if Test B fails then you run Test B's largest subtest etc. Until one of them doesn't fail. Then you have located the failure as well as you can with the given tests, F
