=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.

So you're proposing a domain specific mini-language that you can use to specify the arguments that your subroutine takes, and then use that to generate the code for the tests. You then edit the generated tests too add stuff that's not handled by the mini-language. Yes?

I'm suspicious of generated code that needs editing. If you have to update the functionality at a later date then you need to regenerate the code, and then reintegrate the edits - which can be a painful process.

Wouldn't it be simpler to implement your mini-language as a Test::Builder based Test:: module and skip the whole code-generation side?

Hopefully this makes some vague sort of sense :-)

Of course if you edited the generated file(s) than you'd have problems later if you change something but I don't see any need to. You can have several test scripts for one module. So some files will be generated and some will be writen by hand. I don't see a problem.

I actually like this suggestion ... if the mini-language is simple enough it might make things easier.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature