Re: Reporting setup problems separately?

2007-07-24 Thread Gabor Szabo
SKIP might be a good idea to avoid running tests that cannot work due to some missing prereq or bad environment or whatever but it still does not solve the reporting problem. There can be calls like this ok($ok, "environment is ready"); and calls like this ok($ok, "system under test works well

Re: Reporting setup problems separately?

2007-07-24 Thread David Golden
On 7/24/07, Adam Kennedy <[EMAIL PROTECTED]> wrote: He's doing it within a single test script, BAIL_OUT is for the entire series of test scripts. "die" is BAIL_OUT for a single test :) That works. Or use a SKIP block. David

Re: Reporting setup problems separately?

2007-07-24 Thread Adam Kennedy
David Golden wrote: On 7/24/07, Gabor Szabo <[EMAIL PROTECTED]> wrote: In the way it is written now both setup-phases-failure and real-failure are displayed in the same way. When it fails I know something went wrong but I don't know if it is in the test environment (e.g. not enough disk space) o

Re: Best Practice for tracing program flow

2007-07-24 Thread Matisse Enzer
On Jul 23, 2007, at 10:10 PM, Michael G Schwern wrote: Matisse Enzer wrote: What's the current best practice for running a Perl program and getting a report of all the subroutine calls throughout the life of the program in the order in which they were called? (as opposed to something like

Re: Reporting setup problems separately?

2007-07-24 Thread David Golden
On 7/24/07, Gabor Szabo <[EMAIL PROTECTED]> wrote: In the way it is written now both setup-phases-failure and real-failure are displayed in the same way. When it fails I know something went wrong but I don't know if it is in the test environment (e.g. not enough disk space) or it is in the produc