Hi,
Is that normal that in the following method we do "EX PASS" (at the
end)?
runCaseForDebug: aTestCase
[ aTestCase announce: TestCaseStarted withResult: self.
aTestCase runCaseManaged.
aTestCase announce: TestCaseEnded withResult: self.
"To not affect performance of big test suites following logic is not
inside addPass: method"
errors remove: aTestCase ifAbsent: [ ].
failures remove: aTestCase ifAbsent: [ ].
self addPass: aTestCase ]
on: self class failure , self class skip , self class warning ,
self class error
do: [ :ex |
ex sunitAnnounce: aTestCase toResult: self.
EX PASS ]
I think it is the source of the infinite crazy debugger bug (maybe i'm
wrong) https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger
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:
doesNotUnderstand: aMessage
<debuggerCompleteToSender>
| exception resumeValue |
(exception := MessageNotUnderstood new)
message: aMessage;
receiver: self.
RESUMEVALUE := EXCEPTION SIGNAL.
^exception reachedDefaultHandler
ifTrue: [AMESSAGE SENTTO: SELF]
ifFalse: [resumeValue]
In normal cases (class of the receiver is not a test case), when you
step in the debugger the EXCEPTION SIGNAL blocks the execution right
away.
In subclasses of TESTCASE, it does EX PASS each time you signal the
exception and so it continues in the doesNotUnderstand.
Then it enters the AMESSAGE SENTTO: SELF in the doesNotUnderstand, which
is still not understood and goes again into the "ex pass", then you can
wait a long time...
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).
See TestExecutionEnvironment>>watchDogLoopFor:.
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...
Steven.
