I also posted this to the London Perl Mongers list, and from the feedback there, it seems that I wasn't quite as clear as I should have been. I see this as being a way to auto-generate the repetitive simple tests that I hate writing - exactly the ones that are needed for the example I gave. Any more complex method still needs all those tests to make sure that it is getting at least part of its argument sanity-checking correct. I do not propose that any such mechanism should completely obviate the need to write some tests by hand.

Even if I use Params::Validate or Class::Contract I'd still need to write those sorts of tests, just to check that I've used those modules correctly.

Your point about it maybe making the module harder to read is a good one, although one which can - I hope - be solved by choosing the right syntax.

Can you give an example of the kind of things you would want to generate? I'm not getting a clear idea of what you're expecting.

My first reaction is that the need to generate repetitive tests would be a code smell indicating that some abstraction in the code is being missed - but that may be because I'm missing your point :-)

For the example I gave:

=item addgroup

Takes one parameter, which may optionally be named 'group'.
We detect whether it is a named parameter or not by checking
for the presence of 'group' followed by anything else in the
arguments.  This should be a valid groupname (ie consists
solely of word characters) which does not exist.  If that's
OK, an empty group is created.  All errors are fatal.
[download]

I'd want to somehow encode that so that it could spew out the tests to make sure it dies if the number of arguments is wrong or if the one significant argument matches /\W/. This would be several tests. I would then add tests manually to make sure it dies if the group already exists, and to make sure it creates a group correctly.

Some programming courses teach "write tests first"

Writing tests first is an excellent practice, but often leads to an unfortunate tendency for developers to ignore further whitebox methods. Agile methods talk about writing your tests, then writing your code until you get a green bar. A green bar at this stage should *not* be taken as a pass, but only an indicator that the code now fullfills its contract. That is insufficient to pass the code. Branch and boundary coverage simply can't be analyzed until after the code is written.

A green bar at this stage should *not* be taken as a pass, but only an indicator that the code now fullfills its contract. That is insufficient to pass the code. Branch and boundary coverage simply can't be analyzed until after the code is written.

While I take your point, the test-first response would be that if boundary behavior is important then it forms part of the code's contract, and so there should a test for it.

Branch and statement coverage should come out at 100% if you've been doing TDD properly, since you shouldn't have been writing any code that wasn't motivated by a failing test.

Not that whitebox testing and coverage tests are useless of course - but with a team doing TDD they're much more useful as pointers to where areas where TDD is being skipped or done poorly.

While I take your point, the test-first response would be that if boundary behavior is important then it forms part of the code's contract, and so there should a test for it.

Boundary tests do not just refer to API or requirements describable boundaries. You can have an algorithm that makes choices based on ranges of internally calculated values. Obviously, in TDD, you cannot predict internal algorithmic branches and range conditions and so you cannot write tests that will necessarily exercise all internal branches and boundary conditions. To put it another way, for any reasonably non-trivial routine that you have what you think is a sufficient set of unit tests for, someone could reimplement that routine in such a way that your current test suite still passes but fails to exercise all branches of the code.

It's obvious that tests do not cease (edit: typo FIXED!) to evolve after the code is complete. However, it should be stated that (if you do have a solid API) writing tests first has some advantages. Namely, you can make sure you implemented your entire API and that API works.

Once you start scrolling through hundreds of lines of code, it's hard to visualize your API use cleanly because you start to confuse the API with the implementation. Again, I don't do this nearly enough, but it has great merits and this is something I *should* do for larger projects.

By all means, tests should evolve while the program is written -- however boundary coverage should be one of the first kinds of things you think about when testing your API. That is what automated testing is for. If your API passes all tests, and the whole of your API is tested, you won't have any issues with coverage...harder said than done.

Naturally, testing code by hand is critical in validing that the tests themselves are valid.

It's obvious that tests do not evolve after the code is complete

Depends on your definition of complete. My code collects a new test every time I discover a bug :-)

By all means, tests should evolve while the program is written -- however boundary coverage should be one of the first kinds of things you think about when testing your API. That is what automated testing is for. If your API passes all tests, and the whole of your API is tested, you won't have any issues with coverage...harder said than done.

See the reply to adrianh above regarding internal/algorithmic boundary conditions.

TDD is an *excellent* practice. Didn't I start out with that line? I am only trying to get the point across that it isn't the be-all and end-all of testing, it has limitations.

Steve McConnell's Code Complete 2nd Ed. cites research indicating that while developers think they are getting high code coverage in testing, in reality they get 80% at best, 30% at worst, and around 60% on average. 60% is very, very, very low code coverage. The studies aren't recent, but if anything has changed I suspect it is only that developer confidence has risen, not that test coverage has.