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

The thing is, I would like to save time by using the debugger to simply watch the relevant variable, rather than tediously stepping through line by line.

e.g. something like:-

DB<1> w $current_test DB<2> c
[download]
The debugger should then break whenever the variable's value changes.
Update

In fact, the above wouldn't work, since it would stop on every test.

Update 2

e.g. something like:-

  DB<1> w $current_test == 8  # NB this doesn't work!
  DB<2> c
[download]

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

Replies are listed 'Best First'.
Re^3: Get the number of the current test when debugging a test script by 1nickt (Canon) on Jun 30, 2015 at 17:34 UTC
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!	[reply] [d/l] [select]
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]


Pathologically Eclectic Rubbish Lister
	PerlMonks