Various criticisms of Maths::factorial... it was not intended as a serious contribution to the world of mathematics. Just to help illustrate a set of tests where knowing the line number of a test failure alone is not especially helpful - because that line number performs multiple tests. Whether using die/warn/carp or Test::More, to figure out which test fails, it's helpful to provide a name (or if you'd prefer "message") for each test.

Ergo: those modules make work; get in the way; cut down my options and produce "results" I have no want for nor need of.

Really the only extra work I've felt myself having to do to satisfy Test::More is making sure each test file has a count of the total number of tests contained within it. It is good sense to do so, because if some logic error in the test file causes some of the tests to be skipped accidentally, then I want to know about it. And the only way that the test suite can automatically tell me is if it knows how many tests I intended to run.

Now, Test::More doesn't force you to provide this number. You run tests without a "plan", but I prefer not to for the reason above.

If I wanted the planning feature, and to be informed when the plan was not fulfilled, without using Test::More, then this would actually create a lot more work for me. Test::More saves me work.

When everything runs correctly, I want silence. (Or at the very most "All tests past".) Anything else is just noise.

This is where prove comes in. For example, for PerlX::Perform comes with three test files. The first contains just one test; the other two contain 15 tests each. (The third is a copy of the second, but with different options passed to PerlX::Perform->import. Yes, I could probably handle this better, in a way that doesn't require me to repeat myself.)

But anyway, getting back to the prove facility. Running prove by default gives me a line for each test file, plus a short summary at the end:

t/01basic.t ....... ok   
t/02performing.t .. ok     
t/03whenever.t .... ok     
All tests successful.
Files=3, Tests=31,  1 wallclock secs ( 0.13 usr  0.02 sys +  0.33 cusr  0.02 csys =  0.50 CPU)
Result: PASS

If I want things quieter, prove -Q suppresses the line for each test file:

All tests successful.
Files=3, Tests=31,  1 wallclock secs ( 0.12 usr  0.01 sys +  0.29 cusr  0.02 csys =  0.44 CPU)
Result: PASS

Going the other direction, I can make things more verbose with prove -v

t/01basic.t ....... 
1..1
ok 1 - use PerlX::Perform;
ok
t/02performing.t .. 
1..15
ok 1 - The object isa PerlX::Perform::Manifesto
ok 2 - Things should be executed if scalar is defined
ok 3 - Zero is still defined
ok 4 - Things should not be executed if scalar is undefined
ok 5 - Things should be executed if scalar is defined (wherever first)
ok 6 - Things should not be executed if scalar is undefined (wherever first)
ok 7 - Things should be executed if scalar is defined (wherever first, plain coderef)
ok 8 - Things should not be executed if scalar is undefined (wherever first, plain coderef)
ok 9 - Things should be executed if scalar is defined (wherever first, skip then plain coderef)
ok 10 - Things should not be executed if scalar is undefined (wherever first, skip then plain coderef)
ok 11
ok 12
ok 13
ok 14
ok 15 - Wherever is actually optional
ok
t/03whenever.t .... 
1..15
ok 1 - The object isa PerlX::Perform::Manifesto
ok 2 - Things should be executed if scalar is defined
ok 3 - Zero is still defined
ok 4 - Things should not be executed if scalar is undefined
ok 5 - Things should be executed if scalar is defined (whenever first)
ok 6 - Things should not be executed if scalar is undefined (whenever first)
ok 7 - Things should be executed if scalar is defined (whenever first, plain coderef)
ok 8 - Things should not be executed if scalar is undefined (whenever first, plain coderef)
ok 9 - Things should be executed if scalar is defined (whenever first, skip then plain coderef)
ok 10 - Things should not be executed if scalar is undefined (whenever first, skip then plain coderef)
ok 11
ok 12
ok 13
ok 14
ok 15 - whenever is actually optional
ok
All tests successful.
Files=3, Tests=31,  1 wallclock secs ( 0.13 usr  0.03 sys +  0.33 cusr  0.03 csys =  0.52 CPU)
Result: PASS

In reply to Re^10: Developing a module, how do you do it ? by tobyink
in thread Developing a module, how do you do it ? by mascip

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.