Re^3: Get the number of the current test when debugging a test script

So why not add your own variable at the point at which you want to stop, in the test in which you want to stop, and have the debugger watch for that? Even that seems way overcomplicated.

Like jeffa, I get along faster just dumping to STDOUT; you can confess if you need a trace, and in spite of the OP subject line, you do know which test is failing and where, because of the harness output, right?

Remember: Ne dederis in spiritu molere illegitimi!

Comment on Re^3: Get the number of the current test when debugging a test script Select or Download Code

Replies are listed 'Best First'.
Re^4: Get the number of the current test when debugging a test script by Dumu (Monk) on Jul 01, 2015 at 09:47 UTC
I like the debugger: it allows you to break, then perform multiple test examining variables, data structures etc. without getting mixed up in all of your program's other output. Also, you don't have to mess up your source code with print statements. I do use print, say, Data::Printer, Data::Dumper etc. as well. The debugger allows you to do all that but wtih more flexibility, as well as trace code execution, of course. It's like fast-forwarding through a movie instead of taking a photograph - in a way. If you want the debugger to stop at a place in the source code, you can just type: `$DB::single=1;` [download] This puts a breakpoint in the Perl code. You can then just type 'c' at the DB prompt to zoom straight there. Update And to answer your question properly, I do use test comments. But test comments need not be unique (they may not be if you're running someone else's tests, even if yours are) and are often similiar to other test comments. I caught sight of the test number after which the bug was occurring in the test output, and I wanted to know how to go straight there with the debugger. That's all.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Get the number of the current test when debugging a test script
by Dumu (Monk) on Jul 01, 2015 at 09:47 UTC

I like the debugger: it allows you to break, then perform multiple test examining variables, data structures etc. without getting mixed up in all of your program's other output. Also, you don't have to mess up your source code with print statements.

I do use print, say, Data::Printer, Data::Dumper etc. as well. The debugger allows you to do all that but wtih more flexibility, as well as trace code execution, of course. It's like fast-forwarding through a movie instead of taking a photograph - in a way.

If you want the debugger to stop at a place in the source code, you can just type:

$DB::single=1;
[download]

This puts a breakpoint in the Perl code. You can then just type 'c' at the DB prompt to zoom straight there.

Update

And to answer your question properly, I do use test comments. But test comments need not be unique (they may not be if you're running someone else's tests, even if yours are) and are often similiar to other test comments.

I caught sight of the test number after which the bug was occurring in the test output, and I wanted to know how to go straight there with the debugger. That's all.

[reply]
[d/l]