No, it's not Test::Class I'm carping about. Most of the time it's features I've wanted in Test::Class, not bug fixes.

As for detecting the broken functionality programmatically, the only thing I thought of was using B::Deparse to get the source code of the subroutine and create a digest for it after and compare that with the new sub. That involves embedding the digest and recreating if necessary. Also, just because the source code doesn't change doesn't mean the bug wasn't fixed elsewhere.

If I'm misunderstanding you or you have a better approach which doesn't involve running the code, please let me know. (Hmm, creating local test suites targeting external modules?)

If I'm misunderstanding you or you have a better approach which doesn't involve running the code, please let me know. (Hmm, creating local test suites targeting external modules?)

What I was thinking off was something like this. If Bar::foo(N) has a bug where it dies where N=0, when it should just return -1, then I might only apply my patch where eval { Bar::foo(0) } == -1 is false.

Of course this relies on whatever broken behaviour we're looking for being cheap to test for with no side effects. Make vague sense?

That makes perfect sense, but the problem isn't what the code is currently doing. The problem is that we don't know what the code will do in the future.

Cheers,
Ovid

New address of my CGI Course.