in reply to RFC: Basic Testing Tutorial

Very nice!!

I just have a couple of very minor ideas.

Replies are listed 'Best First'.
Re^2: RFC: Basic Testing Tutorial
by hippo (Archbishop) on Jul 11, 2019 at 09:44 UTC

    Thanks for taking the time to read the tutorial and for your suggestions. I've added an example of is now as that is pretty fundamental.

    While I do take your point about done_testing it would be very easy for a beginner to miss the last step of reverting to a specific plan at the end and therefore maybe miss that the number of tests is not as expected. As it is documented in full in Test::More anyway I'm not entirely convinced of the benefit of repeating that here.

    I'm slightly more minded to mention t as a directory for tests but again if the user is at that level, they're probably looking more at module-writing tutorials where that's covered nicely - and I've already linked to Discipulus's great post on that at the end. Does it need mentioning here still do you think?

      I don' t know where it falls in skill or teaching target but I strongly prefer the done_testing($n) idiom. The main reason is it lends itself to flexibility and a bit of intention documentation in growing/maintaining tests, for example cases like this–

      my %tests = ( case1 => { input => …, output => … }, case2 => { … } ); subtest "Something" => sub { plan skip_all => "Moon is not full" unless …; ok 1; ok 2; done_testing(2); }; for my $test ( values %tests ) { ok $test->{input}, "Have input…"; is process($test->{input}), $test->{output}, "Process works"; } done_testing( 1 + 2 * keys %tests );
        I strongly prefer the done_testing($n) idiom.

        From the responses I have received it appears that you are far from alone in this. I've updated the tutorial to mention done_testing() now. Thanks.

      it would be very easy for a beginner to miss the last step of reverting to a specific plan at the end

      Yes, that's true - it's fine to leave it out, of course.

      mention t as a directory for tests

      An alternative to explaining how to set up a t directory might be to just mention prove's default behavior when not given a filename, something along the lines of "You can give prove a list of test files to run, or if you don't give it any filenames, it'll look for files matching t/*.t and run those." - that might give enough of a hint.