Pre-implemented Services, reusable UI components and unit testing setup

[Supereg]

Pre-implemented Services, reusable UI components and unit testing setup

♻️ Current situation & Problem

This PR iterates on the original PR #9 that introduced the first version of the DSL approach for the new version of SpeziBluetooth. This PR is used to address some major issues in the initial design, improve thread safety while adding some additional features around the core DSL language and implementing proper unit testing. The release notes touches on the new feature in more detail.

⚙️ Release Notes

• Introduced a proper Thread model, having one single Bluetooth background thread responsible for all state interactions. We moved away from the Observable framework for internal state tracking fixing a lot of state tracking issues.
• Introduced a new BluetoothServices target that provides reusable Bluetooth Service implementations like DeviceInformationService or a HealthThermometerService.
• Introduced new BluetoothViews target that provides reusable View components to present nearby Bluetooth devices to the user.
• Introduced SwiftUI Preview support that allows to easily inject custom values or actions into the Characteristic, DeviceState or DeviceAction property wrappers allowing for easy previewing of Bluetooth related views in SwiftUI.
• Added a TestPeripheral executable target (and a corresponding TestService implementation in BluetoothServices) that is used for our unit testing approach.

📚 Documentation

Documentation was updated where required. New targets received their own Documentation Catalogs.

✅ Testing

This PR added unit tests to test the core functionality of SpeziBluetooth in a real-world scenario. We provide a TestPeripheral implementation and unit tests that are expected to run on real device and connect to a the test peripheral.

📝 Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

Attention: 651 lines in your changes are missing coverage. Please review.

Comparison is base (e8f7da9) 22.85% compared to head (17a0d95) 73.49%.

❗ Current head 17a0d95 differs from pull request most recent head ed21790. Consider uploading reports for the commit ed21790 to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##             main      #10       +/-   ##
===========================================
+ Coverage   22.85%   73.49%   +50.64%     
===========================================
  Files          48       78       +30     
  Lines        2022     3523     +1501     
===========================================
+ Hits          462     2589     +2127     
+ Misses       1560      934      -626     

Files	Coverage Δ
...s/BluetoothServices/HealthThermometerService.swift	100.00% <100.00%> (ø)
...rvices/TestingSupport/CBUUID+Characteristics.swift	100.00% <100.00%> (ø)
...BluetoothServices/TestingSupport/TestService.swift	100.00% <100.00%> (ø)
...ces/SpeziBluetooth/Bridging/BluetoothScanner.swift	100.00% <100.00%> (ø)
...luetooth/Coding/FixedWithInteger+ByteCodable.swift	100.00% <ø> (ø)
...uetooth/Configuration/DiscoveryConfiguration.swift	76.93% <ø> (+23.08%)	⬆️
...ooth/Configuration/CharacteristicDescription.swift	76.93% <ø> (+76.93%)	⬆️
...oreBluetooth/Configuration/DeviceDescription.swift	75.00% <ø> (+46.43%)	⬆️
...oreBluetooth/Configuration/DiscoveryCriteria.swift	62.50% <100.00%> (+48.22%)	⬆️
...reBluetooth/Configuration/ServiceDescription.swift	76.93% <ø> (+76.93%)	⬆️
... and 52 more

... and 5 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e8f7da9...ed21790. Read the comment docs.

[Supereg]

As far as I can see, the main thing holding us back would be the runner setup on our build agents?

Yes, this is the primary blocker for this PR right now.

[PSchmiedmayer]

@Supereg I got the macOS builds to work. I added a development signing certificate + two development provisioning profiles in the secrets. In addition I had to add the Apple World Wide Developer certificate from the Continuous Integration setup script as this was missing on the runner.

For the documentation: I had to enter the password once to allow UI automation on the macOS runner and I had to press allow Bluetooth once to allow the Bluetooth usage. I suspect that can not easily automate pressing the Bluetooth alert?

But apart from all of that: We are now ready to merge this PR 🎉

[Supereg]

Thanks for the awesome work. This is really a major step forward to have real-world testing for the Bluetooth library.

I added the gist of your comments and some additional considerations (I had to turn of the screen saver) to the documentation catalog of the TestPeripheral target.

I suspect that can not easily automate pressing the Bluetooth alert?

We might be able to automate pressing the bluetooth alert depending in which process is it launched. But you will have to manually allow the UI testing always.

But apart from all of that: We are now ready to merge this PR 🎉

🚀

[Supereg]

Some discovery, I needed to explicitly allow UI automation testing again. Not sure if there is an ability to "always allow"?

EDIT: Seems to be resolved by running automationmodetool enable-automationmode-without-authentication once. Documented as well 👍