Reporting setup problems separately?
Hi, I have a test that looks like this: ok(prepare_first(), first prepared); ok(test_first(), first is working); ok(prepare_second(), second prepared); ok(test_second(), second is working); That is, there is a phase where I setup the test environment and then there is the actual test. Obviously each phase can consists of several ok() functions. 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 product I am testing. I would like to be able to display them in a different way. Currently the only thing I could think of it making sure the label of each ok() call in the setup phase starts with the word CONFIG and then let the harness understand this. I wonder how do other do this? Gabor
Re: Best Practice for tracing program flow
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 Devel:Profile which lists all the subs, and how many times each sub was called, but not in the order they were called.) Devel::DProf's dprofpp has -T and -t options to display the subroutine call tree. I won't say its best practice, but it should work. Devel::DProfLB works, too. Same author as Devel::Profile. Thank you, I will one or both. -M --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
Re: Reporting setup problems separately?
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) or it is in the product I am testing. If the setup phase fails, is there any point to continuing the tests and showing the real failures? That seems like an ideal situation for BAIL_OUT($why). 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 :) And I'm afraid the only thing that comes to mind for me is a special string in either OK or the diagnostics. Adam K
Re: Reporting setup problems separately?
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
