testing AsyncValueObservation

[yqiang]

This might be more of a Swift Concurrency question rather than a GRDB question, but I thought I'd try to get the communities advice.

Context

I have a SwiftUI view that is powered by a view model which fetches & keeps data fresh using a ValueObservation. I've recently migrated to using AsyncValueObservation and kick it off using SwiftUI view's task modifier. A simple example could be

struct MyView: View {
  @Bindable var viewModel: MyViewModel 

  var body: some View { 
    List(viewModel.data) { item in 
        ForEach(item) { Text(item.name) }
    }
    .task { await viewModel.observeData() }
  } 
}

The observeData method on the view model (an @Observable) creates a ValueObservation and then does a for try await loop to update the items as needed. This works great and SwiftUI automatically manages the lifecycle of the task (i.e., cancels it when the view disappears).

Problems

Now I'd like to write some tests for my view model using Swift Testing and am running into a few stumbling blocks:

Kicking off the observeData method in a test

How can I ensure the observation task starts and fetches the initial data before proceeding with assertions? Here’s what I’m doing now:

    let semaphore = AsyncSemaphore(value: 0)
    
    Task {
      semaphore.signal()
      await viewModel.observeData()
    }
    
    await semaphore.wait()
    await MainActor.run {}

    // now we can resume with our test code and assume that the data has been fetched at least once

This approach works but feels clunky. Are there better patterns for handling this?

Testing updates

When a user swipes to delete an item, the corresponding entry is removed from the database, and the ValueObservation updates the view model with the new data at some point. How can I await this update in my test?

[StuClift]

Are you looking for this https://developer.apple.com/documentation/testing/testing-asynchronous-code?

[yqiang]

I've definitely looked at that but haven't found anything that would be helpful for the specific issue I have. It's possible though that I'm missing something. Do you have a specific example of how I could use the confirmation tool?

[groue]

This approach works but feels clunky.

We have to wait for something. So maybe "clunky" refers to await MainActor.run {}. Indeed I'm not sure it guarantees with 100% certainty that the fresh values were notified and that you can proceed with assertions. And at some point in the future viewModel.observeData() could evolve and await for something else before observing the database, and break the tests.

How can I ensure the observation task starts and fetches the initial data before proceeding with assertions?

Testing async sequences is difficult because it is unclear when the iteration has started. There is a forum thread with a lot of discussions about this topic at Reliably testing code that adopts Swift Concurrency?

I would highlight this particular answer. The general idea is to make the ViewModel testable. Good news: it is already, thanks to @Observable, which comes with a built-in way to let tests know that a value was modified.

If SwiftUI knows that views should be updated, tests can know as well, and maybe this is exactly what the tests should do.

Here is a rough sketch of such tests, one for the initial value, another for an update.

import GRDB
import Observation
import Semaphore

@MainActor @Observable final class MyViewModel {
    var playerCount = 0
    private let reader: DatabaseReader
    
    init(reader: DatabaseReader) {
        self.reader = reader
    }
    
    func observeData() async {
        let counts = ValueObservation
            .tracking(Table("player").fetchCount)
            .values(in: reader)
        
        do {
            for try await count in counts {
                playerCount = count
            }
        } catch {
            // Handle error
        }
    }
}

@Suite
struct MyTests {
    let dbQueue: DatabaseQueue
    
    init() throws {
        dbQueue = try DatabaseQueue()
        try dbQueue.write { db in
            try db.create(table: "player") { t in
                t.autoIncrementedPrimaryKey("id")
            }
            try db.execute(sql: "INSERT INTO player DEFAULT VALUES")
        }
    }
    
    @Test
    @MainActor func wait_for_first_value() async throws {
        let vm = MyViewModel(reader: dbQueue)
        #expect(vm.playerCount == 0)
        
        // Wait for first value
        let semaphore = AsyncSemaphore(value: 0)
        withObservationTracking {
            _ = vm.playerCount
        } onChange: {
            semaphore.signal()
        }
        let task = Task {
            await vm.observeData()
        }
        defer { task.cancel() }
        await semaphore.wait()
        
        // Proceed with assertions
        #expect(vm.playerCount == 1)
    }
    
    @Test
    @MainActor func wait_for_change() async throws {
        let vm = MyViewModel(reader: dbQueue)
        #expect(vm.playerCount == 0)
        
        // Wait for first value
        let semaphore = AsyncSemaphore(value: 0)
        withObservationTracking {
            _ = vm.playerCount
        } onChange: {
            semaphore.signal()
        }
        let task = Task {
            await vm.observeData()
        }
        defer { task.cancel() }
        await semaphore.wait()
        
        // Wait for second value
        withObservationTracking {
            _ = vm.playerCount
        } onChange: {
            semaphore.signal()
        }
        try await dbQueue.write { db in
            try db.execute(sql: "INSERT INTO player DEFAULT VALUES")
        }
        await semaphore.wait()
        
        // Proceed with assertions
        #expect(vm.playerCount == 2)
    }
}

I have reused AsyncSemaphore, since it looks like you use it already. It is a great testing tool indeed. The same result can be achieved with withCheckedContinuation:

@Test
@MainActor func wait_for_first_value() async throws {
    let vm = MyViewModel(reader: dbQueue)
    #expect(vm.playerCount == 0)
    
    // Wait for first value
    var task: Task<Void, Never>?
    await withCheckedContinuation { continuation in
        withObservationTracking {
            _ = vm.playerCount
        } onChange: {
            continuation.resume()
        }
        task = Task {
            await vm.observeData()
        }
    }
    defer { task?.cancel() }
    
    // Proceed with assertions
    #expect(vm.playerCount == 1)
}

[yqiang]

Thanks, this is exactly what I was looking for. It never occurred to me to use withObservationTracking in the view model, and this does seem like a better way to test what would happen in the corresponding SwiftUI view.