I voted 10000-100000, but I don't know if tests in loops count the amount of times a tests is run, or the number of tests actually written (as in typed by hand).

use Test::More;
is (1, 1, "test 1");
is (2, 2, "test 2");
is (3, 3, "test 3");
done_testing ();
[download]

vs

use Test::More;
is ($_, $_, "test $_") for 1 .. 3;
done_testing ();
[download]

As an example only. Generated tests can be complicated but useful.

foreach my $nl ("", "\n", "\r", "\r\n") {
    ok ($object->send ($text.$nl), "send");
    is ($object->receive (), $text, "receive text without line ending"
+);
    }
[download]

does this count as 2 or as 8?

It is the number of tests executed that counts, not the number of statements. So for planning purposes in your first loop your test plan should be 3. The second test plan should be 8.

That being said, I run tests with no_plan simply because counting the number of tests can be annoying to keep up with and I don't think it really adds much to the tests anyways. I rather put more time into test code coverage instead.

Then switch to a newer Test::More, and use - as I did in my example - to the use of done_testing () and you don't have to count or use plans no more.

done_testing () was first released in version 0.88 in May 2009, so it should be available to you too.

Once you're comfortable with this new way of writing tests, you can even spend more time writing them without worrying if you missed count. Next step could be writing subtests :)


Enjoy, Have FUN! H.Merijn

Oh dear, I took a test to mean one test script.. Hmm.. what's a hundred times fifty? I feel that - really- tests should be relatively small- because stuff should be broken up into pieces of code- so.. if your project consists of ten classes, maybe each should be separated and tested into its own module/distro/package. I have a couple of packages that have maybe forty or fifty different test files, and i feel today that this is a failure in development.

Seeing the vast field of not-yet-test features and combinations of features, I guess we really need at least twice as many, possibly more.

fnord

Nice poll!

The responses show that we can still learn a lot from the master:

Chuck Norris can unit test entire applications with a single assert.

I voted 10K - 100K. Back in 1980 or so I wrote virtually all the microcode for the instruction set of a bit-sliced machine. By far the largest amount of microcode was the test set --- millions of lines of souce. Almost all of that was, of course, written automatically from templates.

Paul

Circa: 80 million. Though I admit I didn't actually write any of them.

I did write the test case generator though, so it sort of counts.

no_plan for me!

For me, writing tests is all about the war between sloth and discipline. Anything that makes it easier to write tests, like not having to update that dumb number all the time, means more test get writ.

Tests? It Works For Me...

In the beginning of a project I start writing tests before coding, when the deadline comes nearby and my stresslevel starts peaking I start to omit them. Bad habit, but inevitable, when a manager made some interesting promises.

A great one atcroft...

Here's one way to get started quickly with testing, in about 10 lines of code.

I recently wrote my first tests to drive a Java CLI app, and the investment was repaid quickly when they were easily ported to a second project w/ a similar CLI. I spent less time manually testing, and was more confident about changing the code because I could quickly test it.

The program has a simple command-line menu of about 10 items. I tested the program manually using that menu, which became tedious during development. So I looked at the excellent book: Perl Testing, A Developer's Notebook (ISBN 9780596100926). The section on Testing Interactive Programs in chapter 9 worked for me. (I had previously read the book and written a few tests. If you are new to testing, start at the beginning instead of the end, if necessary). The man pages for the test modules are also helpful.

I needed Test::Expect for this solution. That required me to make a unique and consistent prompt string in the programs under test, which was a good thing.

My first test looked like this:


use strict;
use warnings;

use Test::More tests => 3;
use Test::Expect;

expect_run(
    command => "java -cp '.' src/TestRoster",
    prompt => " >: ",
    quit => "0\n",
);

expect_send( '97',    'Ask for help');
expect_like( qr/-Help about the menu items.+Terminate.+/sm,  '... show
+s help text');
...
[download]

Test 1: print the program's Help menu:
Initialize with expect_run(): the command to run the program under test; the expected prompt; and how to terminate it.
Send the request from the test program (97); see the response at the console (the program's help text); write a regex in the test program to match the response (qr/.../). You now have a test.

Run that Perl test program individually; or use 'prove' to run one or more tests, and to show a summary of the output.

Write a test before you write the code for the next action. Run it, see it fail; write the code; run the test; repeat until no failures. You are now doing test-driven development.

Thanks for the tip on 'done_testing()'.

The only test that counts is the one that would kill the project from someone else... Mua, ha, ha!

Sometimes I find the tough sell to management is not so much the number of tests, but the ratio of test cases to original lines of code, or time spent writing tests.

     tests? like uncommenting my print statements?!
[download]

Wow! I was surprised when I looked at the current poll and found it to be my earlier suggestion. Just-wow.

My original reason for the idea was that I had started myself a small project in late January: I wanted to write something to standardize the abbreviations used in a lengthy list of customer addresses where I work. I started with a listing of US Postal Service abbreviations, and began writing expressions to check for common variations and replace them. In doing so, I realized I could use the Test::* framework to generate tests to make sure none of the patterns I had created were too lax or too aggressive, plus it would give me a reason to play with testing, something that I too have not done as much of as I should. When my generated count of tests exceeded 1.0e4, I began to wonder how many tests others had created/generated/written, and thus the question I posted. (As for the project, I ran out of to-its with a full 10+ minute run of the tests (exceeding 5.8e5, including, at that point, 9 failures), probably several dozen expressions left to write, and the eventual intent to try my hand at morphing it into some kind of usable module.)

613,026 tests (generated by the script), taking 11m:50s to run, and all passed. I'm surprised (on all counts)!

By the way, are there any modules anyone could recommend that actually do what I seem to have originally intended when I started this, to be able to give it an address part (such as an address line, or a US state) using a possibly common abbreviation and return one in which the common but not standard abbreviations are replaced? Just curious.

Catalyst::Devel had a shit load before and has even MORE tests now after my Google Summer of Code project. Test::Aggregate ftw.

$ prove t/library/past*.t
t/library/pastpattern.t ............. ok         
t/library/pasttransformer.t ......... ok   
t/library/pasttransformerdynamic.t .. ok   
t/library/pastwalker.t .............. ok   
t/library/pastwalkerdynamic.t ....... ok   
All tests successful.
Files=5, Tests=2161, 18 wallclock secs ( 0.38 usr  0.05 sys + 16.40 cusr  0.66 csys = 17.49 CPU)
Result: PASS

2,161 as of right now. That number is probably about to go up significantly as I've recently re-factored the code in question a lot, and I haven't written new tests for some of the new functionality.

It's Not Quite a Perl project, although it is a Not Quite Perl 6 project. It's a optimization and analysis framework, originally for Parrot Abstract Syntax Trees(which Parrot's Compiler Tools framework uses), but now rather easy to extend to any tree-like data structure.