in reply to Test::Code

However, I often want to verify that these functions are correct without executing them

I have to admit that I find this intriguing. I'm always more interested in what my functions do than what they look like. Any chance of expanding on why you find this useful?

Naming niggle: I'd expect is_code to be a test for something being a subroutine, rather than a test for equality. Maybe code_is or code_eq?

Replies are listed 'Best First'.
Re^2: Test::Code
by xdg (Monsignor) on Aug 12, 2005 at 11:45 UTC

    I had the same question. I suspect the examples above are abstracted from a more complex real-world problem. In what situation is this useful? (Code-generating code? Code with major side effects?)

    And for the record, I also think "code_is" or "code_eq" would be better. Or, if you're using B::Deparse, perhaps even "deparse_eq" as that's really the most descriptive of what you're doing (i.e. comparing the parse tree of two separate pieces of code) as opposed to seeing if two code_refs point to the same piece of code or anything along those lines.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
Re^2: Test::Code
by Ovid (Cardinal) on Aug 12, 2005 at 17:33 UTC

    I agree that the name is bad. I do plan to change it. As for why I might not want to execute the code, think about "HOP." 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.

    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.

    Cheers,
    Ovid

    New address of my CGI Course.

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

[reply]

In Section Meditations