Re^9: Developing a module, how do you do it ?

[BrowserUk]

Hm. I spent an hour responding in detail to your example. When I return, the example has changed out of all recognition. That's a losing game. Who knows what will be here when I come back, if I start over.

Even with the turn around, you are still producing factorial( 0) == 0 when it should (by convention) be 1.

And then what is the point of testing 0 through 7? Are you expecting Perl to forget how to do math? Or recursion? Why not test 8 through 170?

You have no tests pertaining to 32/64-bit integer limits; or detecting when results start becoming inaccurate due to floating point round-off.

But those are test failures, not those of the test tools.

In vastly abbreviated summary. Nothing your test suit does cannot be done more simply and with less work, without the hierarchy of modules you use; or even with them but in the same file.

But many of the things I routinely do whilst testing cannot be done with those modules in place.

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

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

When something fails, I want to go straight to the source of the failure. I don't need to try and paraphrase the code of each test in three words of English, because once I'm at the line that failed, I can see what that line does.

So once again, *I* have no use for those modules. They require *me* to do (at least) twice as much work to achieve the same result. That is *my* (deeply considered) opinion.

I appreciate that your opinion is different. I'm not stopping you from using whatever cpu-sapping, productivity sapping methodologies and make-work working practices you feel you need to fit in.

[tobyink]

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

Read more... (2 kB)

[BrowserUk]

This is where prove comes in.

No. No. Absolutely no.

What you are saying is that if you use Test::* which produces all this extraneous garbage; then you can use this other tool -- with some set of magical incantations -- to throw that all(*) that garbage away. That is pure make-work.

I'll say it one last time. These modules: a) do nothing I can't more easily do myself; b) give me nothing extra I want; c) steal from me things I need; d) thus preventing me from obtaining things I value.

(*)Almost. You still get this fatuous bunch of crude:

Files=3, Tests=31,  1 wallclock secs ( 0.13 usr  0.03 sys +  0.33 cusr
+  0.03 csys =  0.52 CPU)
Result: PASS

Why would I care how many files there are or tests they contain? Am I going to decide to not install because there are too many files? Will I not reject it if they are all put into a single file? Or maybe I'll reject it if there are too few tests?

Why do I care how long the tests took to run? Either I was sat here waiting for it to complete, in which case I have a very good idea of how long it took -- measured on the scale of: it didn't take too long cos I didn't interrupt it. Or I was doing something else and don't care at all. Now, if they could tell me how long it is going to take; that would be of value. But telling me after the fact how long it took, is utterly pointless.

Finally, I've just seen "All tests successful"; what value does "Result: PASS" have?