Thank you for all the comments.

I would expect that the generated code would be so simple that it wouldn't be worth it.

I find generated stubs pretty useful. They take care of all the preamble, the constructor, the deconstructor, the POD, the inheritance, and sometimes even basic argument validation.

Start with PPI for the parsing, and then build up a simple model of the classes based on what you see.

That's a good idea. I was initially thinking of writing something with Test::More's interface, which created a parse tree instead of validating tests. PPI would probably give me more flexibility, though.

It occurred to me also that all I need to do is create a Module::Starter-like script and execute that. Then all the style guidelines and formatting conventions get taken care of...

I would use the method names used for can_ok to generate the method stubs.

Yep. :-)

what if you have typos (in method names) in the test

Presumably you'll see them when you edit the generated code. If not, then there's little difference from typing them wrongly in the module file. I suppose, though, that if we saw can_ok called many times for one method, and once or twice for a typographically similar method, we could warn...

I realise that methods exist to develop modules and tests from a class definition.

Are there some CPAN modules for that? Could you list them for me? Thanks.

Not exactly, but modules like Class::Generate, Module::Starter (probably what you're looking for), Class::Std, and Object::InsideOut all help with automating this kind of thing.

I sometimes use a homegrown solution which builds hierarchies from definition files something like this:

Foo
  can baz, speak, and glark.
  kids must speak
  uses Whuffle
  Bar
    has length of 10, breadth of 10, snickerer of only 0 or 1, and wei
+ght matching "^\d+".
    can mutate returning Mutator, breed returning Breeder, and telepor
+t.
  Glark 
    can yodel loudly or softly, sing. 
    inherits Traits::Charm.
[download]

This creates Foo::, Foo::Bar, and Foo::Glark all with constructors, preamble, and skeleton POD. All classes inherit from their parent unless you tell them otherwise. The "can" line specifies their methods, and the "has" their attributes. Accessors and mutators are automatically generated. "kids must speak" creates a Foo->speak stub method which complains loudly unless overridden by Foo::Bar and Foo::Glark. Foo::Bar->length defaults to '10', Foo::Bar->snickerer defaults to '0' and can only be changed to '1'. Foo::Bar->weight ensures that its argument starts with a number. There's more to it, but you get the picture. I prefer this approach because it lets me visualise my class hierarchy and brainstorm about who does what. My script creates the module files, generates a basic test suite, and more.

This is essentially all test driven development does; one produces a (partial) definition of a simplified subset of program behaviour called "tests" (which is hopefully simple enough to be correct), and a second, authoritative definition of program behaviour, called "the program". If the two definitions are inconsistent, you have a problem; one of them is wrong (probably the program, but possibly the test suite). Once you specify your tests so completely that they're your program, you've hopefully written a simpler program. Then the question becomes: can you write the tests in an even simpler, more obviously correct way using the new programming language you've just developed? It never ends...

Heh! I'm not looking to write the program from the tests; just the outline of a module hierarchy. The "OO framework", if you like. I'm reasonably familiar with the complexities of compiler writing. ;-)