Useful Debugging Tip of the Day

Ovid on 2008-01-30T15:06:34

I frequently have tests in tight loops. These are often Web spiders or other things and trying to stop on just the right test number can be annoying. Test::Most helps by optionally stopping the tests on the first failure, but in this case, I'm trying to track down sporadic warnings, not failures. Turns out it happens right after test 10, so I have this:

my $builder = Test::Builder->new;

foreach my $thing (@things) {
    $DB::single = $builder->current_test == 10;

    ... all my testing code ...
}

When using the debugger, I hit 'c' for continue and it nicely halts right before the offending code.

You can also see a similar stunt Schwern pulls by using $DB::single to halt when an anonymous subroutine meets the right conditions.

---

Re: Useful Debugging Tip of the Day

jmcnamara on 2008-01-30T17:05:02

On a (sort of) related issue, is there a Test:: module that will allow you to test only 1 or more tests from a large group of tests?

For instance say test 99 of 100 starts failing and you would like to run it on its own. Is there any module that you can "use" to run only that test so that you don't see the output of the tests before or after. Something like:

        use Test::More tests => 100;
        use Test::Only '99'; ...

John.
--

Re: Useful Debugging Tip of the Day

Ovid on 2008-01-30T17:29:01

No, there's nothing like that. Part of the problem is that you get tests written like this:

ok $some_test;
# change the state
ok $some_other_test;

If you change the state between tests and only run the second test (and not code before it), this fails. You could write your own prove which only shows failing tests, but that will likely lose diagnostic information since that goes to STDERR.

However, you can get this behavior if you're willing to switch to Test::Class. See Running Individual Tests in the documentation. It works by setting the TEST_METHOD environment variable to a regular expression which matches only those test methods you want to run.

I have a vim mapping to automate setting the test method.

Penultimate debug-nana

jjore on 2008-01-30T21:56:35

On the bus today, I succeeded in throwing a die(), having that pull a debugger into a previously debugger-less program, and then having it restart execution some N frames up from that as if there'd never been an exception.

Re:Penultimate debug-nana

Ovid on 2008-01-31T09:37:36

Code? I'd love to see that.

Debug on failure

schwern on 2008-01-31T09:16:44

Now here's a much better argument for "end of test" actions than "die on failure": Debug on failure. I'd definitely put in some work on Test::Builder to make that easier.

Re:Debug on failure

Ovid on 2008-01-31T14:10:39

I'd be very happy to see that. I know that my 'die on failure' code has concerned a few people, but it's also pushing the state of the art in testing forward. I also have the luxury that I can take risks like this without threatening the entire tool chain.