libfprint/tests
Benjamin Berg 3108ac3144 virtual-device: Return empty no-match if unknown SCAN id is passed
This matches the expectation. i.e. we return no-match and we do not
return a scanned print as we don't have anything for it. If we did
indeed return a scanned print, then fprintd would try to delete it
during enroll and would then fail.

Note that we do *not* return a DATA_NOT_FOUND error in the storage
device if the print does not exist. This is because not all devices
support reporting this error. It is therefore more sensible to handle it
gracefully and expect test setups to set the error explicitly for
testing purposes.
2021-08-19 18:59:38 +02:00
..
aes3500 tests: Add trailing newline to busname/devname sysfs attributes 2021-01-21 11:28:47 +00:00
egis0570 tests: Add test for egistec0570 2021-07-08 13:42:22 +02:00
elan tests: Add trailing newline to busname/devname sysfs attributes 2021-01-21 11:28:47 +00:00
elanmoc elanmoc: Adjustments to protocol change (passing an empty user ID) 2021-08-10 16:22:54 +08:00
elanspi tests: Add capture test for elanspi 2021-06-23 20:42:52 +00:00
goodixmoc device: Expose supported features publicly as FpDeviceFeature 2021-04-12 22:14:06 +02:00
nb1010 Add nb1010 driver 2021-04-12 20:24:13 +02:00
synaptics tests: Use pcap recording for synaptics and test clear_storage 2021-06-17 14:35:47 +02:00
upektc_img tests: Add upektc_img test 2021-07-12 17:06:43 +02:00
vfs0050 tests: Add full USB device hierarchy 2021-08-09 16:08:21 +02:00
vfs301 tests: Add trailing newline to busname/devname sysfs attributes 2021-01-21 11:28:47 +00:00
vfs5011 tests: Add full USB device hierarchy 2021-08-09 16:08:21 +02:00
vfs7552 Added test for vfs7552 2021-03-12 11:29:43 +01:00
capture.py device: Expose supported features publicly as FpDeviceFeature 2021-04-12 22:14:06 +02:00
hwdb-check-unsupported.py ci: Add check that wiki and generator are in sync 2021-01-20 17:21:38 +01:00
meson.build tests: Add upektc_img test 2021-07-12 17:06:43 +02:00
README.md tests: Allow multiple tests per driver 2021-06-25 10:23:42 +02:00
test-device-fake.c tests: Add suspend/resume tests 2021-08-09 16:08:21 +02:00
test-device-fake.h tests: Add suspend/resume tests 2021-08-09 16:08:21 +02:00
test-fp-context.c tests: Add support for creating other virtual readers 2021-01-20 23:21:04 +01:00
test-fp-device.c device: Deprecate fp_device_{supports,has}_* functions for has_feature 2021-04-12 22:14:06 +02:00
test-fpi-assembling.c assembling: Fix copying only partial tile on overhang 2021-06-23 22:33:07 +02:00
test-fpi-device.c tests: Add suspend/resume tests 2021-08-09 16:08:21 +02:00
test-fpi-ssm.c ssm: Remove delayed action GCancellable integration 2021-04-28 22:16:37 +02:00
test-generated-hwdb.sh test-generated-hwdb: Just use diff to compare for being more informative 2021-01-21 15:55:44 +00:00
test-utils.c virtual-device: Add non-image mock devices 2021-01-20 23:21:41 +01:00
test-utils.h virtual-device: Add non-image mock devices 2021-01-20 23:21:41 +01:00
umockdev-test.py tests: Bump required version for pcap replay 2021-07-12 17:13:43 +02:00
unittest_inspector.py tests: Make meson be aware of the single python unit tests 2020-02-10 11:41:40 +01:00
valgrind-python.supp tests: Add setup mode to run tests using valgrind 2019-11-27 21:40:43 +01:00
virtual-device.py virtual-device: Return empty no-match if unknown SCAN id is passed 2021-08-19 18:59:38 +02:00
virtual-image.py tests: Use native meson exec wrapper in test setups instead of our script 2021-04-13 19:38:58 +02:00

umockdev Tests

umockdev tests use fingerprint devices mocked by umockdev toolchain.

This document describes how to create a 'capture' test: a test that captures a picture of a fingerprint from the device (mocked by umockdev) and compares it with the standard one.

Other kinds of umockdev tests can be created in a similar manner. For match-on-chip devices you would instead create a test specific custom.py script, capture it and store the capture to custom.pcapng.

'Capture' Test Creation

A new 'capture' test is created by means of capture.py script:

  1. Create (if needed) a directory for the driver under tests directory:

    mkdir DRIVER

    Note that the name must be the exact name of the libfprint driver, or the exact name of the driver followed by a - and a unique identifier of your choosing.

  2. Prepare your execution environment.

    In the next step a working and up to date libfprint is needed. This can be achieved by installing it into your system. Alternatively, you can set the following environment variables to run a local build:

    • export LD_PRELOAD=<meson-build-dir>/libfprint/libfprint-2.so
    • export GI_TYPELIB_PATH=<meson-build-dir>/libfprint

    Also, sometimes the driver must be adapted to the emulated environment (mainly if it uses random numbers, see synaptics.c for an example). Set the following environment variable to enable this adaptation:

    • export FP_DEVICE_EMULATION=1

    Run the next steps in the same terminal.

  3. Find the real USB fingerprint device with lsusb, e.g.:

    Bus 001 Device 005: ID 138a:0090 Validity Sensors, Inc. VFS7500 Touch Fingerprint Sensor

    The following USB device is used in the example above: /dev/bus/usb/001/005.

    For the following commands, it is assumed that the user that's running the commands has full access to the device node, whether by running the commands as root, or changing the permissions for that device node.

  4. Record information about this device:

    umockdev-record /dev/bus/usb/001/005 > DRIVER/device

  5. Record interaction of capture.py (or other test) with the device. To do so, start wireshark and record usbmonX (where X is the bus number). Then run the test script:

    python3 ./capture.py DRIVER/capture.png

    Save the wireshark recording as capture.pcapng. The command will create capture.png.

  6. Add driver's name to drivers_tests in the meson.build.

  7. Check whether everything works as expected.

Note. To avoid submitting a real fingerprint, the side of finger, arm, or anything else producing an image with the device can be used.

Possible Issues

Other changes may be needed to get everything working. For example the elan driver relies on a timeout that is not reported correctly. In this case the driver works around it by interpreting the protocol error differently in the virtual environment (by means of FP_DEVICE_EMULATION environment variable).