in reply to Re^3: Automatic generation of tests
in thread Automatic generation of tests

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.

Replies are listed 'Best First'.
Re^5: Automatic generation of tests
by adrianh (Chancellor) on Feb 25, 2004 at 11:54 UTC
    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 :-)

[reply]

      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

[reply]
        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.

        I got the impression that DrHyde was proposing to edit the tests after generation from his OP - but I may be mistaken.

        So some files will be generated and some will be writen by hand. I don't see a problem.

        I just don't see the need for code generation. You can still have a mini-language and without separate code-generation of the tests.

        The only advantage I can see is not having to ship the generator with the tests, but this seems a minor inconvenience compared to the hassles of generating and regenerating the test suite.

[reply]

In Section Meditations