Some tests may have different behaviors depending on the CPU load when
using parallel tests, so async results could arrive in different order.
Then we need to accept multiple results:
- A specific exception has to happen all the times
- One of the accepted exception has to happen all the times
- No exception or one of the allowed exception may happen
Depending on the test, use one of the possible strategies.
As per GDBus we can now get async calls (from the same client) happening
while we're still processing a previous request, so we need to ensure
that we react properly.
In case we get concurrent requests on EnrollStart/EnrollStop we'd just
continue with the operation, making the first processed request to start
the process and the second to hang (in code before the introduction of
stoppable_action_stop()) or to crash (in the current code).
So in such case we should always check that we're not handling already
the request, by checking priv->current_cancel_invocation value.
Add tests to verify the race.
Add a method to delete only a Fingerprint for a device, this is required
by they g-c-c UI design and at the same time it reflects the libfprint
API, where so far only a fingerprint at time can be deleted.
libfprint v1.90.4 introduced a new finger status API to expose to the UI
the finger status on sensor.
Add two new properties to the Device interface that represent the
possible values.
Add new tests.
In the usual test we cancel the operation immediately by calling
VerifyStop. This (often) tests the case where we don't end up restarting
the Verify operation internally.
We can easily force fprintd to have restarted already internally, so add
a test that does so by sleeping a bit. This should give us a slightly
higher branch coverage in the verify_cb/identify_cb tests.
If someone has started an operation, then we don't really need to
confirm they are permitted to stop it again. Not doing this has the
advantage that we cannot run into a second interactive authorization
step accidentally.
But instead only wait for name to appear and do the tests in the main
function so that we can properly check the exception and depending on
its type skip the test or raise it so that it can be caught by the test
suite
If we rely on CI_PROJECT_NAME being set, then the test will fail in
similar environments outside of the fprintd main CI. So just add a
os.stat call afterwards to check whether the permission changes took
effect, and if not, then skip.
So, instead try to create a file and check that this fails.
The code to pick up the utilities from the test environment would fail
if the environment variables are not set. In that case, we can just use
the binary name and rely on PATH though.
This makes the meson output nicer, as it will correctly display that the
test has been skipped. It only happens if all tests in the run were
skipped, but meson always does one test a time.
Simulate the case in which multiple users are trying to access a device
at the same time, verifying that the access is granted only to the one
that first completes the authorization phase and that no other client is
then allowed.
We need to be able to hack this to be an async daemon to perform some
multi-thread tests, so replacing default implementation with a simple
one that for now just does same of default
unittest addCleanup calls are called in reverse order, so we need to reverse
the order of the calls as well, otherwise we won't correctly terminate the
subprocess children
An assertion that is raised within a callback will not be swallowed by
the C code that called the function. To ensure that errors will be
noticable, pass the result back to the surrounding scope and check it
there.
This excercises the path where we early-report a result and the
VerifyStop call must wait for the operation to complete intenernally.
Note that this test cannot fail right now due to the FpImageDevice
internal code still trying to hide the deactivation delay internally.
See libfprint!174
