Test fails on mako #3 utopic

[Alan Pope 🍺🐧🐱 🦄]

http://ci.ubuntu.com/smokeng/utopic/touch/mako/3:20140429.1:20140411.3/7811/ubuntu_clock_app/
http://ci.ubuntu.com/smokeng/utopic/touch/mako/4:20140430:20140411.3/7815/ubuntu_clock_app/

For example:-
http://ci.ubuntu.com/smokeng/utopic/touch/mako/3:20140429.1:20140411.3/7811/ubuntu_clock_app/1056037/

Traceback (most recent call last):
  File "/home/phablet/autopilot/ubuntu_clock_app/tests/test_alarm.py", line 70, in test_add_single_type_alarm_must_add_to_alarm_list
    self.page.add_single_alarm(test_alarm_name, tomorrow_day)
  File "/usr/lib/python3/dist-packages/autopilot/logging.py", line 46, in inner
    return f(instance, *args, **kwargs)
  File "/home/phablet/autopilot/ubuntu_clock_app/emulators.py", line 415, in add_single_alarm
    self._confirm_alarm_creation(old_alarm_count)
  File "/home/phablet/autopilot/ubuntu_clock_app/emulators.py", line 443, in _confirm_alarm_creation
    raise ClockEmulatorException('Error creating alarm.')
ubuntu_clock_app.emulators.ClockEmulatorException: Error creating alarm.

[Nekhelesh Ramananthan (nik90)]

Okay so I tested on device and found that after creating a weekday alarm (Mon-Fri), the alarm does get created but only after about 15 seconds. Autopilot does not wait that long while checking if an alarm was created. This causes the test to fail. I am however only to reproduce this on my Utopic phone. On the trusty desktop and jenkins, the tests seem to pass without any issues.

[Leo Arias (elopio)]

Nekhelesh, so is this an application bug? Should the creationg take less than 15 seconds?
Or should we extend the duration of the wait?

[Nicholas Skaggs (nskaggs)]

This is something to take up with the EDS folks to see why it's taking so long. ATM nik90 and I agree nothing in the test should change, and if anything EDS might be able to have a test to ensure setting an alarm doesn't take so long. Our expectation currently is that this should set pretty much instantly, and that fails within the test tolerance.

Of course if EDs provides feedback that taking longer is expected behavior we will update the test timeout accordingly.

[Nekhelesh Ramananthan (nik90)]

Ok we have two solutions here,

1. Patch the AP tests to wait longer to avoid the test prematurely ending. This will make the tests pass. (Quick and dirty solution) that Leo and Nicholas wouldn't really be happy about since it involves ignoring issues that could potentially exist in the upstream project.

2. Investigate deeper into the SDK and EDS and figure out why the alarms are taking that long to be saved. This could take time since it depends on the availability of the SDK and EDS devs. I talked to Renato on IRC, he will first be merging https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-1309041/+merge/216395 and then investigate the delay in saving alarms.

The question is if this MP needs to be merged asap? If this can wait, then I would prefer going with the second solution.

[Łukasz Zemczak (sil2100)]

I would say like this: if I have to choose between masking issues or fixing them correctly, I prefer the second option. I just want to make sure that this is being worked on and that these issues won't take infinity. Since we already have these problems since a week.

So, if you could keep things coordinated and keep the landing team up-to-date, then I'm happy with 2.

[Nekhelesh Ramananthan (nik90)]

@Lukasz Yeah I will ensure that this gets fixed in the next week.