Test case fails because of StackState's hidden values.

[cihankisakurek]

Description

Hello,
I am currently updating my TCA 0.55 project to TCA 1.1.0 and new navigation store. Migration part went pretty well however I am stuck in an issue with test store.

Test function looks like this.

and the error output is

testOpenURLAcceptInvitation(): A state change does not match expectation: …

      AppDomain.State(
        _destination: .tournamentList(
          TournamentListDomain.State(
            _destination: nil,
            path: [
    −         #1: .tournament(…)
    +         #0: .tournament(…)
            ],
            tournaments: [],
            emptyState: nil,
            isLoading: false
          )
        ),
        receivedURL: nil,
        userAuthState: nil,
        pendingInvitationId: "64e8ad3d104b8781570765bf"
      )

(Expected: −, Actual: +)

which was very confusing for me and I dug a little bit deeper and in TestStore.swift:1019 there is an equality check that fails and if I print and diff the expectedWhenGivenPreviousState and actual state I got this

which confused me some more.

Also I have a very similar test case that works.

Only difference I can see is that in the second case I send the action .navigateToTournament and in failing case it is a receive.

Thanks in advance.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

TestStore's send and receive calls should behave same.

Actual behavior

there is a discrepancy between TestStore.send and TestStore.receive

Steps to reproduce

please see the explanation

The Composable Architecture version information

1.1.0

Destination operating system

iOS 16

Xcode version information

Version 14.3 (14E222b)

Swift Compiler version information

swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
Target: arm64-apple-macosx13.0

[mbrandonw]

Hi @cihankisakurek, this is discussed in our episodes and in the docs, but in order for StackState to work the way it does it needs to maintain an internal list of IDs. And if you ever create new StackState from scratch (like you do in your test), then you will generate all new IDs.

Instead of doing that there are helpers on StackState that allow you to traverse into an element and further into a case of the Path.State enum and make a mutation:

state.path[id: 0, case: /Path.State.feature] = …

This will preserve the IDs and allow you to mutate state.

Also, this is not an issue with the library so I am going to convert it to a discussion. Feel free to ask more questions over there.

[mbrandonw]

It looks like you also have some Destination enum state too, and there is a similar helper on that too, but it uses the @PresentationState projected value:

state.$destination[case: /Destination.State.feature] = …

[cihankisakurek]

I see. But it doesn't explain to me why it is passing the test in the second case.

[mbrandonw]

We make a copy of the \.stackElementID generator when invoking the send and `receive trailing closures:

swift-composable-architecture/Sources/ComposableArchitecture/TestStore.swift

Lines 900 to 905 in 6dfdd18

	let currentStackElementID = self.reducer.dependencies.stackElementID
	self.reducer.state = previousState
	self.reducer.dependencies.stackElementID = previousStackElementID
	defer {
	self.reducer.state = currentState
	self.reducer.dependencies.stackElementID = currentStackElementID

This means if you are testing a feature that appends a new element to a stack, and so it generates id #0, and in the assert you do path = […], then you will generate another id #0 in that assertion.

Honestly, in retrospect, I do not think we should have done that logic in the test store. And we should probably remove it in 2.0. Instead your second test should be written as:

state.$destination[case: /Destination.Action.feature]?.path[id: 0] = …

This makes it clear you know what generational ID is being used for your newly pushed feature.

[cihankisakurek]

Thank you for your explanation it make sense now. Yes I agree. I always assumed they would behave exactly the same (since a user action and a side effect should be same) but I guess it is a design choice in some sense.

Anyway thanks for your time and also for this great library!

[seanmrich]

I ran into a similar problem while testing path mutations. In my setup, child features use delegate actions to notify a root feature to modify the navigation stack. Here, the Child feature is just a button that should push an Other feature.

@Reducer
struct Child {
  enum Action {
    case itemTapped
  }
}

struct ChildView: View {
  let store: StoreOf<Child>
  var body: some View {
    Button("Item") {
      store.send(.itemTapped)
    }
  }
}

The Root feature listens for that delegate action and pushes Other onto the stack.

@Reducer
struct Root {
  @Reducer(state: .equatable)
  enum Path {
    case child(Child)
    case other(Other)
  }
  struct State: Equatable {
    var path = StackState<Path.State>()
  }
  enum Action {
    case path(StackAction<Path.State, Path.Action>)
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .path(.element(_, action: .child(.itemTapped))):
        state.path.append(.other(Other.State()))
        return .none
      case .path:
        return .none
      }
    }
    .forEach(\.path, action: \.path)
  }
}

This setup works fine. Here's how I expect to test that the navigation stack is modified correctly:

@MainActor
func testItemTapped() async {
  let store = TestStore(
    initialState: Root.State(
      path: StackState([
        .child(Child.State())
      ])
    ),
    reducer: { Root() }
  )
  await store.send(.path(.element(id: 0, action: .child(.itemTapped)))) {
    $0.path = StackState([
      .child(Child.State()),
      .other(Other.State())
    ])
  }
}

This test fails as described by the OP because the StackElementID's don't line up. If instead of explicitly describing the state, I use mutations, the test passes.

await store.send(.path(.element(id: 0, action: .child(.itemTapped)))) {
  $0.path.append(.other(Other.State()))
}

This isn't a huge issue, but the test feels less satisfying because I'm not really confirming the entire contents of the stack state. Am I executing these tests correctly?

[mbrandonw]

This isn't a huge issue, but the test feels less satisfying because I'm not really confirming the entire contents of the stack state. Am I executing these tests correctly?

You can also assert like this if you want to assert on the full stack:

await store.send(.path(.element(id: 0, action: .child(.itemTapped)))) {
  $0.path[id: 0] = .other(Other.State())
  $0.path[id: 1] = .other(Other.State())
  XCTAssertEqual($0.path.count, 2)
}

And I suppose we could consider a dictionary-like way of asserting on the stack:

$0.path = [
  0: .other(Other.State()),
  1: .other(Other.State()),
]

We would have to think about it a bit more.

[seanmrich]

Thanks for that. Here's a little extension that gets you pretty close:

extension StackState {
  mutating func assert(_ expected: OrderedDictionary<StackElementID, Element>) {
    for (id, element) in expected {
      guard self[id: id] == nil else { continue }
      self.append(element)
    }
    for removedId in ids.subtracting(expected.keys) {
      self[id: removedId] = nil
    }    
  }
}

Usage:

await store.send(.path(.element(id: 0, action: .child(.itemTapped)))) {
  $0.path.assert([
    0: .child(Child.State()),
    1: .other(Other.State())
  ])
}

Edited: Originally only handled appending paths. Modified to also allow for popped elements