Hello Apple Developer Community and Apple Engineers,
I'm working on a CoreBluetooth-based iOS application and struggling to find clear, official guidance on best practices for unit testing CoreBluetooth functionality. I'd appreciate any insights from the community and especially from Apple engineers on the recommended approaches.
Background & Challenges:
Our team has encountered several challenges when trying to implement comprehensive testing for our CoreBluetooth code:
Subclassing Restrictions: Apple's documentation explicitly states "Don't subclass any of the classes of the Core Bluetooth framework. Overriding these classes isn't supported and results in undefined behavior." This makes traditional mocking approaches (creating mock subclasses of CBCentralManager, CBPeripheral, etc.) problematic for unit testing.
Integration vs Unit Testing Dilemma: We currently use integration tests with third-party libraries like Nordic Semiconductor's CoreBluetoothMock, which work well for end-to-end testing but aren't true unit tests. They test the interaction between our code and the (mocked) CoreBluetooth stack rather than testing individual methods in isolation.
Delegate Method Testing: Our code implements CBCentralManagerDelegate and CBPeripheralDelegate protocols. Testing these delegate methods in isolation is challenging because:
The methods receive CBCentralManager/CBPeripheral parameters that we can't mock via subclassing
Using third-party mocking frameworks makes them integration tests, not unit tests
Testing the business logic within these methods requires the actual CoreBluetooth objects
Simulator Limitations: The only official Apple documentation we found about CoreBluetooth testing is Technical Note TN2295, which is marked as "retired" and from 2012. It describes a complex simulator setup requiring physical USB adapters, suggesting simulator-only testing isn't fully supported.
Specific Questions:
What are Apple's current official recommendations for testing CoreBluetooth applications? Should we focus on device testing, integration testing with mocking libraries, or are there other approaches we should consider?
For unit testing: How can we test individual delegate methods and business logic without violating the "no subclassing" restriction? Are there patterns or architectures that make CoreBluetooth code more unit-testable?
Testing strategy: Should CoreBluetooth applications primarily rely on integration tests rather than traditional unit tests? Is this an acceptable trade-off given the hardware-dependent nature of Bluetooth?
Simulator support: Is there current, supported functionality for testing CoreBluetooth applications in the simulator, or should all testing be done on physical devices?
Current Approach:
We're currently using:
Integration tests with CoreBluetoothMock for comprehensive workflow testing
Limited unit tests for business logic that we can extract from delegate methods
Physical device testing for final validation
This works but feels incomplete compared to the unit testing coverage we achieve in other parts of our application.
Request:
Any guidance from Apple engineers on the intended/recommended approach for testing CoreBluetooth applications would be incredibly valuable. Even confirmation that "integration testing with physical devices is the primary recommended approach" would help clarify our testing strategy.
Thank you for any insights you can share!
Environment:
iOS 17+
Xcode 15+
Swift 5.9+
