Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^2: Eliminating duplicated code in multiple test scripts using Test::More

by TomDLux (Vicar)
on Jul 22, 2013 at 04:44 UTC ( #1045576=note: print w/replies, xml ) Need Help??


in reply to Re: Eliminating duplicated code in multiple test scripts using Test::More
in thread Eliminating duplicated code in multiple test scripts using Test::More

The modern way is to simply invoke use Test::More; at the top, and at the end have done_testing().

If there were problems, they would generate error messages, which are detected by TAP; if there are no errors, the system counts up the successful tests and uses that in the final message.

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

Replies are listed 'Best First'.
Re^3: Eliminating duplicated code in multiple test scripts using Test::More
by choroba (Chancellor) on Jul 22, 2013 at 06:34 UTC
    It is probably modern not to comment out tests. When I do such an ancient thing, I am often glad that Test::More reminds me to uncomment them later when the number of tests does not match.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re^3: Eliminating duplicated code in multiple test scripts using Test::More
by kcott (Canon) on Jul 22, 2013 at 10:06 UTC

    While I'm aware that done_testing($number_of_tests) is a newer addition to Test::More (and, as such, could be referred to as a modern way), I'm not convinced that using done_testing() is the modern way. I can see that I'm possibly misinterpreting your intent: perhaps you could clarify, particularly with respect to any special situations or conditions that you considered implicit in your statement.

    ++choroba makes a good argument for specifying the number of tests. Another, which has certainly happened to me, is being interrupted in the process of writing a series of planned tests and then, on resumption of the task, accidentally skipping one that hadn't been written yet: specifying the number of tests up-front catches that too.

    Test::More's documentation, in the (cutely named) "I love it when a plan comes together" section, has "The preferred way to do this is to declare a plan ..."; and later, in the done_testing bullet point, "This is safer than and replaces the "no_plan" plan.".

    -- Ken

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1045576]
help
Chatterbox?
[choroba]: On the other hand, lots of options to receive the requests :-)
[Corion]: ... values to be used. For example, I think for headers, one would want to have various kinds of Content-Encoding headers, but for the get_parameters one would have various kinds of Bobby Tables
[choroba]: What about [metadoc:// Algorithm::Loops]?
[Corion]: choroba: Yeah, but handing off the request to Dancer,Plack, Mojolicious,LWP is easy once I have the data filled into some structure ;))
[choroba]: Algorithm::Loops
[Corion]: choroba: I'm using that to generate the permutations, but I don't know how the user can pass the intended values to my function in a sane way
[Corion]: I have a prototype that permutes the get_parameters, but the values used for the get parameters should be different from the values used for the headers and potentially for parts of the URL
[Corion]: But yes, in general, my approach will be "split the URL into another set of parameters, generate an array of allowed values for each parameter and then NestedLoops() over the set"
[choroba]: hmm... so you need something like bag from Test::Deep, but not for checking, but for generation
[Corion]: This has the dual use of easily requesting sequential URLs and also being suitable for testing

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2017-01-17 08:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you watch meteor showers?




    Results (152 votes). Check out past polls.