[Pharo-project] testing ui errors in headless mode

Tudor Girba tudor at tudorgirba.com
Tue May 31 23:08:03 CEST 2011


On 31 May 2011, at 22:32, Igor Stasenko wrote:

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

I tried it:

	self shouldnt:  [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise:  Error

But this still fails. You can try using the attached st file.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: headlesstest.st
Type: application/octet-stream
Size: 665 bytes
Desc: not available
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110531/9fd412e4/attachment.obj>
-------------- next part --------------

>> Cheers,
>> Doru
> -- 
> Best regards,
> Igor Stasenko AKA sig.


"The coherence of a trip is given by the clearness of the goal."

More information about the Pharo-project mailing list