[Pharo-project] testing ui errors in headless mode

Igor Stasenko siguctua at gmail.com
Tue May 31 22:32:24 CEST 2011

On 31 May 2011 23:15, Tudor Girba <tudor at tudorgirba.com> 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 <tudor at tudorgirba.com> 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 ).

> Cheers,
> Doru

Best regards,
Igor Stasenko AKA sig.

More information about the Pharo-project mailing list