Hi, I would need a bit of help with this one :).
I tried:
testStartup
self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]]
raise: Error
This still fails. Is there a way around it?
You can try using the attached st file.
Cheers,
Doru
Begin forwarded message:
> From: Tudor Girba <[email protected]>
> Date: 31 May 2011 23:08:03 CEST
> To: [email protected]
> Subject: Re: [Pharo-project] testing ui errors in headless mode
>
> 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." > > > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"
