If you were to try and write tests for the parser, you might find it quite a bit easier to write eq_code $code, $expected; than to constantly create correct subs to pass into code and make them work.
What I'd probably do would be to start with tests asking it to parse some strings - and see where that would take me. I've test-firsted parsers in the past like this without too much difficulty. I might try it your way next time to see what it's like :-)
A problem can also arise when the code being generated does things that you'd rather not execute. Maybe it starts pulling a value off an iterator but you don't want that to happen yet. Maybe it deletes files, closes a filehandle or does other cleanup work that shouldn't happen yet.
In this case I'd want the dangerous stuff off somewhere I could use mock objects and/or dependency injection to make it safely testable.
In reply to Re^3: Test::Code
by adrianh
in thread Test::Code
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |