On 2013-11-11, at 18:41, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:

Hi!

I am trying to fix bug 12138 (https://pharo.fogbugz.com/f/cases/12138/Finding-a-class-is-kind-of-broken)

And I would like to write test like that:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
testSearchSelectAndOK
|classes |
waitSemaphore := Semaphore new.
classes := { Object . BlockClosure. Class }.
listDialogWindow := SearchFacade classSearchIn: classes.
"listDialogWindow open."
listDialogWindow addDependent: self.
listDialogWindow searchUpdate: 'BlockClosure'.
waitSemaphore wait.
listDialogWindow listIndex: 1.
waitSemaphore wait.
listDialogWindow ok.
self assert: listDialogWindow answer notNil.
self assert: (listDialogWindow answer = BlockClosure).

handleUpdate: aMorphChanged 
waitSemaphore signal.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

If I run the test from debugger � context menu on test method and select debug tests � and then I do proceed, it works. If I press the green button in Nautilus which run the test, it is frozen and I have to kill it by Cmd+. The same happens if the test it run from Test Runner.

It waits for testSemaphoreForMethod semaphore in method PackageTreeNautilusUI(NautilusUI)>>runTestForAMethod:notifying:priority:

Hi,

Note that the Debugger uses a separate UI Thread to avoid side-effects.
However if you run the test directly from nautilus this is not the case.
Instead the tests are directly run in the UIThread.

If you do `waitSemaphore wait` you will instantaneously block the UI thread,
which in return means that #handleUpdate: will never be called (since the
UI thread execution halted).

I just propose an outline for a solution (not well thought through.. :P):
Somehow you have to run the test in a separate thread ([...] fork) to make
sure `waitSemaphore wait` does not block the UI Thread. At the same time 
you do not want to wait forever, so #valueWithin:onTimeout: is your friend :)