Failing tests on testbots because of missing focus

Francois Gouget fgouget at codeweavers.com
Sun May 4 04:38:37 CDT 2014


On Sat, 3 May 2014, Bernhard Übelacker wrote:
[...]
> In my opinion the reason is that these tests get executed from an
> application which does not have the current input focus.

On the WineTestBot the tests are being run from a console 
window which is iconized. On the fg-* VMs the mechanism is similar, 
though it's possible the command window is no iconized.


[...]
> Also because the newtb* machines showed this error only sometimes (at
> least before the testbot changes lately) probably some other tests are
> doing something to change focus situation, or are running long enough
> and windows is changing its focus policy there.

Some tests cause Windows to be opened and stay around. In particular I 
remember that WineTest.exe typically leaves an Explorer window behind, 
most likely triggered by a shell32 or shlwapi test. The rpcrt4 tests 
and others also leave firewall windows behind, asking whether to unblock 
various ports (these tests don't actually need the ports to be 
unblocked and thus are not impacted by the questions being 
unanswered [1]).

So based on your description it's quite likely that one of these windows 
is the one with the focus.

[...]
> Because of this affecting more tests (and probably this fix could also affect
> tests running after this one), I am not sure if this is the right way to fix it:
> 
>  - should the test rely on being started from an application which
>    had focus? (e.g. change testbot to start the tests by an cmd window
>    which has guaranteed focus)

Tests that need focus for one of their window should set up the focus 
themselves [2]. More generally tests should not rely on anyone else 
setting things up for them as that would make them too brittle and hard 
for developers to run 'correctly'.


[1] I assume these tests bind their socket to any address and that's why 
    they get these firewall questions. But in fact they only get 
    connections from localhost which is unaffected by the firewall so 
    it's possible they could avoid these questions by only binding to 
    localhost. It's not clear that it's worth the trouble though.

[2] I'll leave checking the proposed code to do so to other, more 
    capable, hands (or eyes, braaaains, as the case may be).

-- 
Francois Gouget <fgouget at codeweavers.com>


More information about the wine-devel mailing list