Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: RFC: Basic Testing Tutorial

by haukex (Chancellor)
on Jul 07, 2019 at 10:02 UTC ( #11102494=note: print w/replies, xml ) Need Help??

in reply to RFC: Basic Testing Tutorial

Very nice!!

I just have a couple of very minor ideas.

  • Maybe mention done_testing as an option? I always start with use Test::More; ...; done_testing;, and then when I'm done with the first pass of writing tests, I switch over to use Test::More tests => N;.
  • Maybe give example of is, since it's a pretty common one?
  • You could perhaps also mention the t directory: it's fairly easy to create a t directory beneath the location of the script being tested, and then just run prove.

Replies are listed 'Best First'.
Re^2: RFC: Basic Testing Tutorial
by hippo (Chancellor) 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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11102494]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2020-02-25 06:50 GMT
Find Nodes?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?

    Results (108 votes). Check out past polls.