[Technical Questions] Testing inaccessible errors

[nick-allen21]

In what area do you have a technical challenge?

Xcode, Simulator & Previews

Description

I am getting a ton of errors saying that I cannot access the private function that I am trying to test on. I have spent sometime debugging and looking up documentation but to no avail.

Reproduction

My TestingTest branch should be public on Quanbio industry repo. You can go to that and try to run the test cases. Here is the code if that would help

`import XCTest
import SwiftUI
@testable import QuanBioSync

// MARK: - Expose the parseAndAppend function for testing.
// You can add this in a separate file in your test target.

@mainactor
extension TestView {
// Changing the access level (or using @testable) allows tests to call this function.
func test_parseAndAppend(_ data: Data) {
self.parseAndAppend(data)
}
}

@mainactor
final class TestViewTests: XCTestCase {

var testView: TestView!

override func setUp() {
    super.setUp()
    // Create an instance of your view.
    testView = TestView()
    // Reset state before each test.
    testView.dynamicData = LocalDynamicRawDataRequest()
    testView.integerDynamicData = IntegerDynamicRawDataRequest()
    // For some tests (e.g. PPG, HRV) the code appends data only if properDataRead is true.
    testView.properDataRead = true
}

// Helper to wait briefly for any async updates.
func waitForAsyncUpdates() {
    let exp = expectation(description: "Wait for async update")
    DispatchQueue.main.async {
        exp.fulfill()
    }
    wait(for: [exp], timeout: 1.0)
}

// Test that an invalid header results in no data appended.
func testInvalidHeader() {
    // Data does not start with 0xff, 0xfe.
    let invalidBytes: [UInt8] = [0x00, 0xFE, 0x18, 0x15, 0x23, 0x96, 0x32]
    let data = Data(invalidBytes)
    testView.test_parseAndAppend(data)
    waitForAsyncUpdates()
    XCTAssertTrue(testView.dynamicData.heartRate.isEmpty)
    XCTAssertTrue(testView.dynamicData.ppgSignal.isEmpty)
    XCTAssertTrue(testView.dynamicData.bloodOxygenSaturation.isEmpty)
}

// Test the SpO2 & PR package (cmdID = 0x95).
func testSpO2AndPRData() {
    // Build a valid SpO2/PR package:
    // Header: [0xff, 0xfe]
    // Length: 0x18, Checksum: 0x15, DeviceID: 0x23, cmdID: 0x95
    // Then for handleSpO2AndPRData, supply:
    //    byte0 = 0x00 (device state 0, no searching, no pulse flag)
    //    byte1 = 60 (pulse rate)
    //    byte2 = 0x5F (SpO2; note: only lower 7 bits used)
    //    4 bytes to skip (we use zeros)
    //    byte7 = 15 (respiration rate)
    let bytes: [UInt8] = [
        0xff, 0xfe, 0x18, 0x15, 0x23, 0x95,
        0x00, 60, 0x5F, 0x00, 0x00, 0x00, 0x00, 15
    ]
    let data = Data(bytes)
    testView.test_parseAndAppend(data)
    waitForAsyncUpdates()
    
    // The closure in updateUIState should have appended one heart rate, one SpO₂, and one respiration rate value.
    XCTAssertEqual(testView.dynamicData.heartRate.count, 1)
    XCTAssertEqual(testView.dynamicData.bloodOxygenSaturation.count, 1)
    XCTAssertEqual(testView.dynamicData.respirationRate.count, 1)
    
    XCTAssertEqual(testView.integerDynamicData.heartRate.count, 1)
    XCTAssertEqual(testView.integerDynamicData.bloodOxygenSaturation.count, 1)
    XCTAssertEqual(testView.integerDynamicData.respirationRate.count, 1)
}

// Test the PPG data package (cmdID = 0x96).
func testPPGData() {
    // Build a valid PPG package:
    // Header: [0xff, 0xfe], Length: 0x18, Checksum: 0x15, DeviceID: 0x23, cmdID: 0x96.
    // Then, for each iteration (the loop runs 5 times), supply:
    //    one PPG data byte (we choose 50, which is < 200)
    //    one skip byte (dummy value)
    var bytes: [UInt8] = [0xff, 0xfe, 0x18, 0x15, 0x23, 0x96]
    for _ in 0..<5 {
        bytes.append(50)  // ppg value
        bytes.append(0x00) // skip byte
    }
    let data = Data(bytes)
    // properDataRead is already set to true.
    testView.test_parseAndAppend(data)
    waitForAsyncUpdates()
    
    XCTAssertEqual(testView.dynamicData.ppgSignal.count, 5)
    XCTAssertEqual(testView.integerDynamicData.ppgSignals.count, 5)
}

// Test the HRV data package (cmdID = 0x97).
func testHRVData() {
    // Build a valid HRV package:
    // Header: [0xff, 0xfe], Length: 0x18, Checksum: 0x15, DeviceID: 0x23, cmdID: 0x97.
    // Then, the loop in handleHRVData runs 5 times (stride from 0 to 10 by 2).
    // For each iteration, we need 2 bytes.
    // We provide 40 as the HRV value (the second byte is ignored).
    var bytes: [UInt8] = [0xff, 0xfe, 0x18, 0x15, 0x23, 0x97]
    for _ in 0..<5 {
        bytes.append(40)  // first byte (used)
        bytes.append(0x00) // second byte (ignored)
    }
    let data = Data(bytes)
    testView.test_parseAndAppend(data)
    waitForAsyncUpdates()
    
    XCTAssertEqual(testView.dynamicData.heartRateVariability.count, 5)
    XCTAssertEqual(testView.integerDynamicData.heartRateVariability.count, 5)
}

// // Test the Battery Level package (cmdID = 0x99).
// func testBatteryLevel() {
// // Build a valid Battery Level package:
// // Header: [0xff, 0xfe]
// // For this package, we use a different length byte (here 0x0c) and a dummy checksum.
// // Then: DeviceID: 0x23, cmdID: 0x99, followed by one byte for the battery level.
// let bytes: [UInt8] = [0xff, 0xfe, 0x0c, 0xbc, 0x23, 0x99, 80] // battery level = 80
// let data = Data(bytes)
// testView.test_parseAndAppend(data)
// waitForAsyncUpdates()
//
// XCTAssertEqual(testView.dynamicData.batteryStatus.count, 1)
// XCTAssertEqual(testView.integerDynamicData.batteryStatus.count, 1)
// }

// Test an unknown cmdID does not update any data.
func testUnknownCmdID() {
    // Build a package with an unknown cmdID (e.g. 0x00).
    let bytes: [UInt8] = [0xff, 0xfe, 0x18, 0x15, 0x23, 0x00]
    let data = Data(bytes)
    testView.test_parseAndAppend(data)
    waitForAsyncUpdates()
    
    // Expect no data to be appended.
    XCTAssertTrue(testView.dynamicData.heartRate.isEmpty)
    XCTAssertTrue(testView.dynamicData.ppgSignal.isEmpty)
    XCTAssertTrue(testView.dynamicData.bloodOxygenSaturation.isEmpty)
    XCTAssertTrue(testView.dynamicData.respirationRate.isEmpty)
    XCTAssertTrue(testView.dynamicData.heartRateVariability.isEmpty)
    XCTAssertTrue(testView.dynamicData.batteryStatus.isEmpty)
}

}
`

`@MainActor
struct TestView: View {
@Environment(MyDevice.self) var myDevice: MyDevice?
@State private var dynamicData = LocalDynamicRawDataRequest()
@State private var integerDynamicData = IntegerDynamicRawDataRequest()
@State private var deviceStateDescription: String = ""
@State private var isNavigatingToPersonView = false
@State private var pulseRate: UInt8?
@State private var SPO2: UInt8?
@State var testRiddle: Riddle = getRandomRiddle()
@State var properDataRead: Bool = false
@State var notifyBool: Bool = false
let totalTime: Double = 90
/// Rest of code

`

Expected behavior

I expected the tests to run

Additional context

No response

Code of Conduct

• I agree to follow this course's Code of Conduct and Contributing Guidelines

[nriedman]

Hi @nick-allen21! The @testable import statement gives internal access (more info about access levels in Swift here). The errors here are when you attempt to access private properties of views.

There is no workaround for this other than changing the access level of the properties of the view, which you might not want to do! Alternatively, you could test this with a UITest instead injecting mock Bluetooth devices. Finally, you could package a lot of the code that manages State into an Observable ViewModel. This is a common design pattern in Swift/SwiftUI that would allow you to expose a lot of functions and state to Internal access level and Unit Testing. However, this would likely require a decent amount of code restructuring.

Let me know if you have any questions about any of these approaches!

[nick-allen21]

Hi Nick, thank you for getting back to me. I will try some of this and get back to you.

[nick-allen21]

Hi Nick, I haven't been creating a mock Bluetooth Device. I have been trying to read an array of bytes into the functions that I use in this test view.

Unit Test Issues : The problem is that I cannot access the functions in test view via a unit tests as you say. Moving them to a place where I can access them would take a large amount of code restructuring as you said. This would likely just end up jeopardizing the integrity of the application. It is a bit late in the development of the app for this and risky the day before the final presentation.

UI Test Issues : The problem is that the app is structured in such manner that I cannot even get to the testing page where almost all the testable code is without recognizing a device, the injected device becomes the navigation link if you remember. The page also brings you back to the bluetooth page if there's no device connected. I have been trying work arounds with feature flags for a long time now and I still cannot reach the testview page. Thus, it seems the only way to do this is UI tests with a mock device that sends mock byte packages through the TestView which I have also been trying for a long time to no avail.

The Bluetooth device is so integrated to this entire workflow and it seems it is going to be a really tall task to test without it, especially with all the error checking that I've implemented to ensure an intuitive user experience.

Let me know if you have any other ideas about how to implement tests for the Bluetooth piece.

[nick-allen21]

Been trying for a while now, I also don't think currently it is possible within Spezi Bluetooth to inject a mock bluetooth object which I can then use in my UI. While I can inject a device into the environment, I cannot make a move scanner. SpeziBluetooth seems to require an actual BLE for advertisement for the service "FFBO" which is my device's signal. Unless I am wrong, it seems extremely hard to do this without the actual hardware sending the signal. There is no "add device" that would let me manual add something to the scanning section which would allow my device to pop up on my UI which will allow me to press the "connect" button where I could then theoretically navigate to my test page.

[nriedman]

Hi @nick-allen21! Nice work looking into these solutions -- testing bluetooth devices seems to be a tall order.

Depending on your implementation, you could take inspiration from this project where we tested accepting measurements by injecting mock data into the data structure that we use to bridge between the Bluetooth device and our app (the HealthMeasurements class from SpeziDevices). This would require a work-around for navigating to the test view without a connected device.

Another option would be to add functions to relevant views for setting and getting the properties you want to access. It could look something like this to workaround the private access level:

struct MyView: View {
    private let privateProperty: String = ""
    
    /// We can use these compiler directives to only compile this code if we are in Test build config
#if TEST
    /// A computed property with internal access level that allows us to get and set the private property
    var testPrivateProperty: String {
        get {
            self.privateProperty
        }
        set {
            self.privateProperty = newValue
        }
    }
#endif

   /// Rest of code (i.e. body)
}

You might be able to inject all the info you need in this way using Unit tests like you initially did -- this seems like a pretty good option that mitigates a lot of the difficulties you are encountering. Let me know what you think! Otherwise, make sure to have everything stable and merged into main before the presentations today. Testing these features is somewhat secondary. Good work! 👍

[nick-allen21]

Hi @nriedman,

Thanks for sharing. That could possibly work. However, I do not think it would work if I still don't have access to the private functions in the test view. And I cannot try this via UI testing because I cannot even open the test page if I do not have a detected device (if I could even get a device injected). I think my group chose to spend our last day refining dead code, writing tests for other portions, and completing documentation. I am happy to talk with anyone on the teaching team in length concerning the fact that we will not be reaching our code coverage requirement.