broken unittest test_mouse_interaction

[Torsten Scheck]

When running
  autopilot run libautopilot_qt.tests.test_main.TestProperties.test_mouse_interaction
it fails:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/libautopilot_qt/tests/test_main.py", line 64, in test_mouse_interaction
    self.pointing_device.move_to_object(mousearea)
AttributeError: 'TestProperties' object has no attribute 'pointing_device'

I fixed it locally (see below), but I wonder why this has not been detected so far.

I've just started to get familiar with autopilot. Is there any CI server which shows when this unittest began to fail?

--- /usr/lib/python2.7/dist-packages/libautopilot_qt/tests/__init__.py 2014-03-12 14:51:09.000000000 +0100
+++ /home/t/functional_tests/libautopilot_qt/tests/__init__.py 2014-04-24 14:38:02.130386589 +0200
@@ -17,12 +17,15 @@
 import logging
 logger = logging.getLogger(__name__)

+from autopilot.input import Mouse

 class AutopilotQtTestCase(AutopilotTestCase):
     qt_version = 0
+ pointing_device = Mouse.create()

     def setUp(self, *app_args):
         super(AutopilotQtTestCase, self).setUp()

[Corey Goldberg (coreygoldberg)]

just for clarification, this is referring to a failing test in libautopilot_qt, not Autopilot itself.

I will try to reproduce, and also will look for the CI server and include details in a followup comment.

[Corey Goldberg (coreygoldberg)]

I reproduced this in the distro version of libautopilot-qt (Trusty).
below is the full stacktrace of running the installed autopilot-qt test suite.

However, I couldn't get the tests to run at all against current trunk version :/ very strage.

cgoldberg@colossus:/usr/lib/python2.7/dist-packages/libautopilot_qt$ python -m unittest discover
.....E....
======================================================================
ERROR: test_mouse_interaction (tests.test_main.TestProperties)
tests.test_main.TestProperties.test_mouse_interaction
----------------------------------------------------------------------
_StringException: Empty attachments:
  process-stdout

process-return-code: {{{-15}}}
process-stderr: {{{Testability driver loaded. Wire protocol version is "1.4".}}}

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/libautopilot_qt/tests/test_main.py", line 64, in test_mouse_interaction
    self.pointing_device.move_to_object(mousearea)
AttributeError: 'TestProperties' object has no attribute 'pointing_device'

----------------------------------------------------------------------
Ran 10 tests in 23.070s

FAILED (errors=1)

[Corey Goldberg (coreygoldberg)]

I just checked the CI server. Seems the autopilot-qt jobs have not been active in the Trusty image for over a month (at which time they were all green on all platforms).

I have no idea why they would be disabled, but will look into it asap.

--Corey

[Corey Goldberg (coreygoldberg)]

Hi Torsten,

> I've just started to get familiar with autopilot.

Nice! and welcome!
we (autopilot hackers) also have an IRC channel on freenode: #ubuntu-autopilot
feel free to drop by if you have questions or want to get more involved.

> Is there any CI server which shows when this unittest began to fail?

the CI environment is undergoing some changes., but somewhere in:
http://ci.ubuntu.com/
... contains what you are looking for, and more. although, as I mentioned in previous comment, the CI tests are not currently running.

I will ask the CI team why the jobs aren't running, and also ask @veebers about the failing testcase/bug, as I think he is doing some current development work in libautopilot-qt. (unfortunately he is on holiday today)

regards,
  -Corey
  (@cgoldberg on freenode irc)

[Thomi Richards (thomir-deactivatedaccount)]

Hi,

On Fri, Apr 25, 2014 at 4:33 AM, Corey Goldberg
<email address hidden>wrote:

> I will ask the CI team why the jobs aren't running, and also ask
> @veebers about the failing testcase/bug, as I think he is doing some
> current development work in libautopilot-qt. (unfortunately he is on
> holiday today)
>

We have an open ticket to get these tests running again. The difficulty is
that we need a CI job that runs the test job in more than one configuration
(qt4, qt5), which is a little tricky.

Cheers,
--
Thomi Richards
<email address hidden>

[Torsten Scheck (torsten-scheck)]

Hi,

Thomi Richards wrote on 28.04.2014 04:16:
> We have an open ticket to get these tests running again.
> The difficulty is that we need a CI job that runs the test job
> in more than one configuration (qt4, qt5), which is a little
> tricky.

with qt it should be feasible to test different version in the same
environment. The CI job environment needs access to both qt4 and qt5 libs
and the QT_SELECT variable needs to be set (e.g. QT_SELECT=qt4).

BTW: I'm pretty impressed by your prompt responses, pro-active follow up
and the overall inviting tone. And the QA team's documentation, tools and
technology are outstanding.

Thank you, Corey and Thomi.

Cheers,
Torsten

--
Torsten Scheck <email address hidden> Jabber:<email address hidden>
GnuPG 1024D/728E 6696 F43D D622 78F1 F481 45C0 2147 69AB DD54
software engineer:open standards/access/knowledge:enthgnusiast

[Thomi Richards (thomir-deactivatedaccount)]

Hi,

On Mon, Apr 28, 2014 at 4:39 PM, Torsten Scheck <email address hidden>wrote:

> with qt it should be feasible to test different version in the same
> environment. The CI job environment needs access to both qt4 and qt5 libs
> and the QT_SELECT variable needs to be set (e.g. QT_SELECT=qt4).
>
>
Yep - that's what we have planned. The problem is not so much figuring out
what to do, but rather getting the overly-busy CI team to implement our
suggestions :)

> BTW: I'm pretty impressed by your prompt responses, pro-active follow up
> and the overall inviting tone. And the QA team's documentation, tools and
> technology are outstanding.
>
> Thank you, Corey and Thomi.
>

No problem - feel free to drop in on IRC if you want real-time conversation.

Cheers,

--
Thomi Richards
<email address hidden>