Re: Integration testing for BlueZ

[Pauli Virtanen <pav@iki.fi>]

Hi,

30. maaliskuuta 2026 12.38.49 UTC Bastien Nocera <hadess@hadess.net> kirjoitti:
>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-v3/test/functional/test_bluetoothctl_vm.py

and test_btmgmt_vm.py

Although these don't currently contain much, but could be extended.

FWIW I'd maybe consider using pytest also for Python regression & unit tests, at least if you can make them run without root.

There's interesting bluetoothd mock dbus library by the bluez-alsa developer, which looks like it could be useful for bluetoothctl/etc utility testing

<https://github.com/Samsung/bluezoo>



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