Andrew Dunstan <and...@dunslane.net> writes: > On 12/8/21 09:08, Dagfinn Ilmari Mannsåker wrote: >> >> Either way, I think we should be switching tests to done_testing() >> whenever it would otherwise have to adjust the test count, to avoid >> having to do that again and again and again going forward. >> > > I'm not so sure. I don't think its necessarily a bad idea to have to > declare how many tests you're going to run. I appreciate it gets hard in > some cases, which is why we have now insisted on a Test::More version > that supports subtests. I suppose we could just take the attitude that > we're happy with however many tests it actually runs, and as long as > they all pass we're good. It just seems slightly sloppy.
The point of done_testing() is to additionally assert that the test script ran to completion, so you don't get silent failures if something should end up calling exit(0) prematurely (a non-zero exit status is considered a failure by the test harness). The only cases where an explicit plan adds value is if you're running tests in a loop and care about the number of iterations, or have a callback with a test inside that you want to make sure gets called. For these, it's better to explicitly assert that the list you're iterating over is of the right length, or increment a counter in the loop or callback and assert that it has the expected value. This has the added benefit of the failure being coming from the relevant place and having a helpful description, rather than a plan mismatch at the end which you then have to hunt down the cause of. - ilmari
