Is that normal that in the following method we do "ex pass" (at the end)?
Doing "ex debug" solves the problem but i do not know the impact (pharo 5 - 6 - 7, but not previous versions).
For what i understand, it happens because :
- when you got an error in a test, it goes through the ex pass
- but when you got a doesNotUnderstand, it first goes into:
In normal cases (class of the receiver is not a test case), when you step in the debugger the
In subclasses of TestCase, it does
Then it enters the
I'm not really sure though why it does not open another debugger and why it gets stuck. Maybe that is the real bug: it should open another debugger and not loop and pop one million debugging windows after a user interruption.
Another side effect is that the watchdog of the TestExecutionEnvironment also gets stuck and stops counting for the timeout, because a debugging session was open and never closed (because its looping).
Replacing ex pass by ex debug seems to work and reproduce the standard behavior of the debugger for classes that are not subclasses of TestCase. But i do not know if the "pass" was explicitly intended and if there will be side effects...
Hi Steven, I'll take a look at this later this week, no time now, but: did you check that the debugger makes a copy of the UI process when there is an exception in the UI process? Because that is also part of the problem I believe.
On Mon, Jun 11, 2018 at 2:18 PM, Steven Costiou <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|