Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: TDD of non-module code

by chrestomanci (Priest)
on Jan 24, 2012 at 13:03 UTC ( #949677=note: print w/ replies, xml ) Need Help??


in reply to TDD of non-module code

  • Put the tests in the code to be executed from the command line. This is the approach I am currently using, but I see a problem ahead. When the development is finished, I don't want the tests to run every time. I imagine that this will mean that I will have to put in code to handle options so that code -t will run tests while code filename will do the real work of processing a file.

That sounds like a sensible idea. You could add a --self-test command line switch, and have it on by default during development, and off when the code is complete. You could even put the test code into a separate .pm file (in the same package) so that you don't have to ship the test code in your deliverable.

An alternative approach would be to create a .t test script that loads and executes your main program, either using system() with a test command line, and then examines the output, or by loading the whole script into a scalar string, and using eval()

Overall though I think it is wiser in the long term to take moritz's advice and make your script act as both standalone and as a module with doit(@ARGV) unless caller; at the end of all your subroutine definitions


Comment on Re: TDD of non-module code
Select or Download Code

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://949677]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2014-12-21 21:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (108 votes), past polls