Debugging is easier if we can explicitly run a single iteration only.
This filter could be a range but for now it's sufficient to be able to
run a single test only.
The Doxygen "Modules" page is not very illuminative, as different parts
of the API are mixed together and not all parts are included.
Try to address this:
Put all parts of the public API to some Doxygen group, usually one group
per header file. Use short, systematic names.
Make these groups sub-groups of a few top-level groups, roughly
corresponding to the different logical parts of the API (core, impl,
stream, filter, spa, utilities).
Having a helper aids with the file being in the right directory and cleaned up
automatically on exit. Plus, failing the test with the sytem error status code
signals that it's not the actual test failing here.
Helper function to load a SPA interface. This enables a test to easily load a
specific interface and run tests against that interface without having to
instantiate a whole pipewire daemon.
Heavily inspired by libinput's litest framework (built around check), this is
a from-scratch framework that simplifies adding tests for various parts of
pipewire. See the pwtest.h documentation for details but the basics are:
- PW_TEST() and PWTEST_SUITE() specify the tests to be run
- Test are run in forked processes, any errors/signals are caught and printed
to the log
- Tests have a custom pipewire daemon started on demand to talk to [1]. The
daemon's log is available in the test output.
- Output is YAML to be processed into whatever format needed
[1] There are limits here, since we can't emulate devices yet there is only
so much we can rely on with the daemon.
