I suspect Dumu is indicating that it is not the test itself that is problematic, but rather, that the harness breaks after running a certain number of tests.
If I am interpretting that correctly, moving the test to a new harness and running only one test will not cause the failure in question.
I could be wrong, but that's how I read it.
| [reply] |
Thanks marinersk, not exactly... the bug was in a specific place in the code. It wasn't being caused by a specific number of tests being run, but it did happen after a certain number of tests had run, simply because that was when the first test was performed on a buggy method.
But anyone in the situation you describe should also find the answer to my question useful.
| [reply] |
Depending on the problem, the two solutions mentioned in this thread tend to cover my approach. I can set up a flag or counter which I set under the right conditions to cause a breakpoint to trigger, or to step up logging levels, or what have you. Or just flip on global debugging, pipe it to a file, load it into a text editor, and keep jogging. Under TDD, the test number makes it easy to jump to the right spot in the debug log.
Having had to support remote web-based applications where logs were the only convenient diagnostic tool available has taught me to have mercy on those who have to support or maintain my code later; I write debug logging into nearly everything these days.
Because of this, I don't think I've used an interactive debugger in...wow, I'm going to have to go with decades.
| [reply] |
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
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
| [reply]
[d/l]
[select] |
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] |
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;
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] |
And I just want to be able to do this with the test number. | [reply] |