You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than merely patching individual dbus objects blindly, we can make the mocked BLE device, mocked WiFi, mocked Helium Api dbus objects using https://github.com/martinpitt/python-dbusmock.
Pros
The mocked BLE device will implement the API like the real device, or at least the parts that we actually need.
As the testing doesn't depend on the real dbus objects, testing environment will be consistent across local, CI(Github Action). For ex, once we make a mocked LTE dbus device, it will work on a machine without LTE device, CI environment in a same way.
Once we made a BLE device template, it can be used across the test cases of all the Characteristics.
Cons
This will bring up extra complexity in the infrastructure of unit testing.
The current unit test cases for Bluetooth are written by using unittest library's
MagicMock
object.https://github.com/NebraLtd/hm-config/blob/master/tests/gatewayconfig/bluetooth/test_bluetooth_connection_advertisement.py#L263-L265
For example, to write unit test cases for
DiagnosticsCharacteristics
(https://github.com/NebraLtd/hm-config/blob/master/tests/gatewayconfig/bluetooth/test_diagnostics_characteristic.py#L20), dbus objects for bluetooth profile, server, helim miner and also need to simulate the pairing behavior of bluetooth device.Rather than merely patching individual dbus objects blindly, we can make the mocked BLE device, mocked WiFi, mocked Helium Api dbus objects using https://github.com/martinpitt/python-dbusmock.
Pros
Cons
Example:
The text was updated successfully, but these errors were encountered: