Hi, On 31 May 2011, at 22:32, Igor Stasenko wrote:
> On 31 May 2011 23:15, Tudor Girba <[email protected]> wrote: >> Hi Igor, >> >> Sorry for the late reply. >> >> >> >> On 26 May 2011, at 17:48, Igor Stasenko wrote: >> >>> On 26 May 2011 17:03, Tudor Girba <[email protected]> wrote: >>>> Hi, >>>> >>>> I tried several ways to get my head around this problem, but I do not know >>>> how to proceed. Can anyone help? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> We have some smoke tests in Moose that basically spawn a UI and check for >>>>> Error. >>>>> >>>>> This used to work when running headless in Pharo 1.2 but now they fail in >>>>> Pharo 1.3. I believe this has to do with the new changes in the UI >>>>> Manager, but I do not know what to do. >>>>> >>>>> To reproduce the problem, you can simply call a Pharo-1.3.image in >>>>> headless mode and file in the attached st file that: >>>>> >>>>> - installs a simple test: >>>>> HeadlessTest>>testStartup >>>>> self shouldnt: [1 inspect] raise: Error >>> >>> Tudor, your test is wrong. >>> During image startup and in headless mode calling inspector will and >>> should raise an error. >>> Because inspecting object requires a presence of UI. >>> But there's no UI in headless mode and prohibited from use during >>> image startup phase, because >>> you cannot start asking questions from user before properly >>> initializing everything related to startup. >>> Startup is called startup on purpose: is should not be interrupted nor >>> require user's interaction. >>> >>> Assume that you don't have Morphic loaded in your image, then what you >>> expect to happen if you do >>> 1 inspect >>> ? >> >> I understand now that the test is wrong. I just wanted to offer an example >> of spawning a ui, but I think I found the problem like this :). >> >> Now, the thing is that my test tests that triggering the entries from a menu >> does not result in an error. And inspect or browse happen to be among the >> menu entries. Is there a way to still have this test working on the server? >> >> Should I put a guard condition in the method triggering the inspector? That >> sounds bad. Any other ideas? >> > > Yes, you could swallow all ErrorNonInteractive. > So if you will know that something will lead to UI interaction, you > can catch ErrorNonInteractive. > Since there is no UI you won't proceed further, but still will know > that during running the test some UI is involved. > > So, actually a following should pass: > > UIManager default isInteractive ifFalse: [ > self should: [1 inspect] raise: ErrorNonInteractive > ] > > The problem is that there is some missing protocol in > NonInteractiveUIManager (because at the time i was adding it , i > covered all methods, > but then some more stuff were added to morphic ui manager without > parallel extension to other ui managers, > so the test above can fail because you will get DNU error instead of > ErrorNonInteractive ) I tried it: testStartup self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Error But this still fails. You can try using the attached st file. Cheers, Doru
headlesstest.st
Description: Binary data
>> Cheers, >> Doru >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."
