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

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.

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

Replies are listed 'Best First'.
Re^3: Get the number of the current test when debugging a test script by Dumu (Monk) on Jun 30, 2015 at 16:46 UTC
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]
Re^4: Get the number of the current test when debugging a test script by marinersk (Priest) on Jun 30, 2015 at 19:05 UTC
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]