The state aggregation test requires an idle handler to run, which can be
a bit unreliable as it may or may not run twice.
Force running it twice and add code to wait for it to complete. Do so
properly by waiting for the correct log messages rather than sleeping so
that everything is ordered nicely while not slowing down the test a lot.
Closes: #193
This adds a test that checks all possible inputs for the battery state
aggregation. Not all states are actually tested in this case, as some
states may be handled through state inference and others might not be
well defined.
The umockdev code to disable it by setting the variable does not
propagate through python. Set the variable here until there is a more
permament solution available.
Using tearDown is brittle, as an assertion will stop it from running
through completely. So move cleanup into a helper that is called via
addCleanup for logind and bluez.
It can be a bit unepxected if results are not printed immediately, so
turn off buffering. We could possibly also reopen sys.stdout, but this
is good enough in many cases.
Instead of just killing upower, try to send SIGTERM for a clean
shut-down. Kill the process if it doesn't quit within two seconds, and
check that the service exits cleanly.
While not needed currently, there is a discussion to ignore the "hid"
subsystem parents when searching for siblings. Add in appropriate
parents to the tests so that such a change will not result in a failure.
This causes an add that we ignore, after that we should still see
updates from the device (and the add itself should trigger an update).
Verify that this works by setting the capacity to 20.
The hiddev driver has been in the "usbmisc" subsystem since kernel 3.7.0
or so. As such, we can simply drop the "usb" subsystem from our matches
at this point.
Otherwise we flush out the data much more often than needed. With this
change, we'll also wait up to 5 seconds even on lower power. Loosing 5s
of data shouldn't be too bad, and it may prevent additional disk writes.
But, more importantly, we need to deferre writing the data to a later
main loop iteration. If we did not do this, then we have an
write-amplification scenario where the history is written at least 4
times instead of once.
Closes: #150
The changes from 37b6d4b039 ("linux: Fix Bluetooth tests for
python-dbusmock changes") require a not-yet-released dbusmock version.
Simply catch the error and fall back to adding the properties in order
to be compatible with both old and new dbusmock versions of the bluez
service.