The main reason not to go this route is that you take away the caller's control over what gets spit out in the case of a test failure What if the caller simply wants to know that the file failed to open and can try another file or just tell the user? Would you really want to log a bunch of TAP output spitting out at the terminal even when the caller considered the exception irrelevant or capable of recovery?
Secondly, I don't see tests outside of a program as duplication at all. They have a very different purpose. When I write tests I'm usually testing a wide variety of inputs to a function. I don't assume an exception is bad, rather I may deliberately provoke exceptions. I want to test to make sure that an exception is thrown when conditions warrant it. Ironically, in some cases a test is passed only when the exception is thrown.
Perhaps your actual goal here is logging? If so, I think you might be better off acquainting yourself with a module like Log::Log4Perl which gives you a permanent record (log file) and a lot of control over how much or how little output is generated and where it is stored.
Or maybe you are inspired in this direction because of the rich assortment of assertions that have already been programed for you and wrapped in test modules? In some cases these can be had without using the test module. For example, Data::Compare can compare arbitrary Perl data structures and Data::Match compares your structure against a pattern.
In reply to Re: Using Test modules in production scripts
by ELISHEVA
in thread Using Test modules in production scripts
by xssnark
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |