Re: Integration testing for BlueZ

[Bastien Nocera <hadess@hadess.net>]

On Wed, 2026-02-25 at 20:58 +0200, Pauli Virtanen wrote:
> Hi,
> 
> ke, 2026-02-25 kello 17:01 +0100, Bastien Nocera kirjoitti:
> [clip]
> > > Feel free to git a review to Lars's patch; hopefully, that will
> > > help
> > > us get this resolved quicker. We might as well create a unit test
> > > for
> > > shell to try to emulate different modes and environments. That
> > > way,
> > > we
> > > prevent introducing regressions like this in the future.
> > 
> > I wrote one, which I can integrate into meson.
> > 
> > This starts "btvirt" (so requires root), launches bluetoothd if
> > there
> > isn't a daemon already running, and launches "bluetoothctl list".
> > 
> > You can run it manually with:
> > $ sudo top_builddir=/path/to/bluez/builddir/ ./integration-test.py
> > 
> > If "bluetoothctl list" doesn't output any text, the test errors
> > out.
> > I've tested that pointing the bluetoothctl_path() output at an old
> > version of bluetoothctl worked.
> > 
> > This pattern of using Python to create test suites using python-
> > dbusmock is something I've already used in PolicyKit, upower,
> > power-
> > profiles-daemon, gnome-bluetooth and many other places.
> > 
> > This test is pretty heavy-handed if we just want to test whether
> > bluetoothctl outputs things correctly, but it has the benefit of
> > testing the emulator as well as bluetoothd. We could start adding
> > more
> > tests to the mix, such as creating more adapters, pairing them,
> > etc.
> > 
> > Hopefully, this is a useful test to run on CIs, although I'm
> > probably
> > missing spawning a system bus on top of everything else.
> > 
> > What do you think?
> 
> Adding some testing for this is a good idea, and I'd think Python is
> the way to go.
> 
> I was planning on pushing this a bit further, and automate also end-
> to-
> end integration testing. That is, QEmu instances connected to each
> other via btvirt, so we can have repeatable tests in a "real"
> environment.
> 
> This is maybe overkill for simple bluetoothctl command line tests,
> but
> it allows things like automated testing of Pipewire <-> Bluez <->
> btvirt <-> BlueZ <-> Pipewire audio setup.
> 
> This involves lots of subsystems, and it's currently 100% relying on
> manual testing and sometimes things are missed, like breaking A2DP in
> some setups in 5.86, or breaking BAP in 5.85.
> 
> Here's a working prototype, needs some more work though so details
> may
> change but the general shape is probably going to stay:
> 
> https://github.com/pv/bluez/blob/func-test/unit/func_test/test_cli_simple.py

Do you still have a copy of the above file somewhere? I wanted to
finish porting them into my own integration tests which I'm hoping to
add to the regression/unit tests that are usually run for every
commit/MR.

> 
> https://github.com/pv/bluez/blob/func-test/doc/test-functional.rst
>