tests: cover existing pair() and unpair() behavior#1993
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1993 +/- ##
===========================================
+ Coverage 52.45% 52.79% +0.34%
===========================================
Files 43 43
Lines 4097 4097
Branches 504 504
===========================================
+ Hits 2149 2163 +14
+ Misses 1817 1801 -16
- Partials 131 133 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
I don't consider the tests with mocks very helpful since it is quite difficult mock how OS-specific Bluetooth works and it tends to change over time. I would rather have just have integration tests for everything. |
|
For example, we should have an integration test where the peripheral returns the error code “Pairing Not Supported” to make sure we have a common exception raised on all platforms. We might also want to have integrations tests for both peripherals that support "LE legacy pairing" (temporary key + short term key) and ones that support "LE Secure Connections" (long term key) to make sure the OS handles both (parameterized tests). Hopefully the OS handles the difference between these transparently, but one never knows. I probably need to do some more reading to see if there are any other interesting cases we would want to test. |
|
I will remove the mocked tests and leave in the integration test. |
Lock in the current BlueZ and WinRT pair()/unpair() contract before the pairing-agent series reworks it, so later refactors cannot silently regress today's behavior. - winrt: idempotent already-paired return, can_pair guard, Just Works success + handler detach, result-status failure, the deprecated protection_level keyword, and unpair status handling. - bluez: already-paired return, Trusted-then-Pair + resolvable-private- address refresh, D-Bus failure propagation (no agent is registered on develop, so a real Pair fails, cf. hbldh#1380 / hbldh#1434), and unpair RemoveDevice / DoesNotExist mapping. - integration: a connect/disconnect/unpair smoke test for the existing unpair path. Expands the integration harness from hbldh#1888. Addresses dlech's request on hbldh#1990 to split the work and add tests for existing pairing functions first. Part of the pairing series continuing hbldh#1864. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
471c094 to
d70bd60
Compare
Split out of #1990 — a regression net for the current
pair()/unpair()behavior, landed first so the pairing-agent work that follows has coverage to change against.What
Adds unit and integration coverage for existing behavior, with no production changes:
tests/backends/winrt/test_pairing.py,tests/backends/bluezdbus/test_pairing.py— unit coverage of the existingpair()/unpair()paths.tests/integration/test_client_pairing.py— bumble integration tests:unpair()of a connected, never-paired device; CoreBluetooth raisesNotImplementedError.Testing
skipif-guarded.🤖 Generated with Claude Code