Dynamic shared keys and testing

[seanmrich]

Have there been any best practices shared on testing TCA features that use dynamic shared keys? Here's an example:

@Reducer
struct Feature {
  struct State: Equatable {
    @Shared(.inMemory("sortAscending")) var sortAscending = true
    @SharedReader var items: [Item] // 👈 This is dynamic based on 'sortAscending'
  }
  enum Action {
    case sortButtonTapped
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .sortButtonTapped:
        // I can verify this change
        state.$sortAscending.withLock { $0.toggle() }
        // Takes some extra work to be sure this happened
        state.$items = SharedReader(.items(sorted: state.sortAscending))
      }
    }
  }
}

struct FeatureTests {
  @Test func sortButton() async throws {
    let store = TestStore(
      initialState: Feature.State(),
      reducer: { Feature() }
    )
    await store.send(.sortButtonTapped) {
      $0.$sortAscending.withLock { $0 = true }
    }
  }
}

When I run code like this I get a passing test even though I haven't mentioned anything about the change to items. Just for fun, I can even throw in a "wrong" assignment in there:

await store.send(.sortButtonTapped) {
  $0.$sortAscending.withLock { $0 = true }
  $0.$items = SharedReader(.items(sorted: false))
}

This still passes. Of course, I can throw in an explicit check after the send and get test coverage for the change, but now I have to remember that each time.

#expect(store.state.items == […])

Any tips on a better approach to this kind of thing?

[stephencelis]

Of course, I can throw in an explicit check after the send and get test coverage for the change, but now I have to remember that each time.

This is the way to go for now. While it's definitely annoying to have to remember to check, remember that this is basically how every test is written outside of TCA 😄

We'd be open to explore extending the exhaustive testing tools to readers, but we're not sure how that would look since readers aren't mutable:

await store.send(.sortButtonTapped) {
  // Syntax already exists and is what you write in the app code as well
  $0.$sortAscending.withLock { $0 = true }

  // What possible syntax could we use to make an exhaustive assertion here?
  $0.$items.???
}

[seanmrich]

Perhaps you could just provide the values you expect as a constant?

await store.send(.sortButtonTapped) {
  …
  $0.$items = .constant([item1, item2])
}

I can't remember whether you guys covered this in videos, but I assume (perhaps wrongly) the assertion is inspecting the wrapped values not the underlying reference. This might be problematic for any key that provides its values asynchronously, though.