Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Starting the development of a module : thoughts

by dragonchild (Archbishop)
on Jun 28, 2001 at 23:26 UTC ( #92427=note: print w/replies, xml ) Need Help??

in reply to Starting the development of a module : thoughts

Are there examples anywhere of what goes into a test suite? How should one build it? Are there any gimmes&gotchas to building test suites? I think it would be neat just for maintenance of personal packages...
  • Comment on Re: Starting the development of a module : thoughts

Replies are listed 'Best First'.
Re: Re: Starting the development of a module : thoughts
by Masem (Monsignor) on Jun 28, 2001 at 23:51 UTC
    What goes into tests is easy: this is the same concept as unit testing for object-oriented languages (C++ and Java). Basically you want to test every 'reasonable' object and function to make sure they work in every 'reasonable' test case that you can think of. While this can be a pain to add after your main program is said and done, the concept of unit testing is that these types of short codebits would be developed while you are developing the classes and functions, so inclusion into the test portions is trivial. Tests should basically make sure you are getting expected results from functions and code, such as:
    sub add { my ($a,$b) = @_; return $a+$b; } # Test code: print "not ok" if add(2,2) != 4;

    Now, what you actually print out is still a bit of a quandry for me; I know that there's info about it (that I happened upon luckily) at perldoc Test and perldoc Test::Harness. From my understanding (please correct me) is that the testing process sits at the end of STDOUT and intercepts everything. The first thing that the test scripts (as a whole) must print out is a "1..N\n" string, indicating the number of tests (=N). Each test then should print out "ok M\n" or "not ok M\n", where M is the specific test number. The test code runs all tests regardless of failures of previous ones, and reports the fraction of tests that failed at the end of the test cycle. When you install from CPAN, you'll see those test modules in action.

    And again, from the docs and other module examples, you either want one full, comprehensive test in the ./ file, or several small test files in ./t/*.t. In the latter case, tests are run in sorted order, which is why many people name files like "01test.t" as to have the specific tests executed in a logical order while still having the name printed out when CPAN-installing.

    Dr. Michael K. Neylon - || "You've left the lens cap of your mind on again, Pinky" - The Brain

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://92427]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2017-01-22 23:19 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (190 votes). Check out past polls.