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 :)