Inversion of Control: In Parent-Child relation, do I always need to declare the reducer for the child? How can I test the action that's handled by the parent reducer? #411
-
Hi,
enum MeetingFooterAction: Equatable {
case skipSpeaker
} In this relation, it's up to the parent - struct MeetingView: View {
let store: Store...
var body: some View {
WithViewStore(store) { viewStore in
...
MeetingFooterView(store: store.scope(state: \.meetingFooterState,
action: MeetingAction.skipSpeaker))
...
}
}
} You can see how I handle this single action here, in MeetingView source file. In this case I didn't have to specify the environment nor the reducer for the Does it then make sense to actually test the As you can see in the code snippet below, I actually provided empty reducer and environment. class MeetingFooterViewTests: XCTestCase {
func testSkipAction() {
let store = TestStore(initialState: MeetingFooterState(speakers: [ScrumTimer.Speaker(name: "John Doe", isCompleted: false)]),
reducer: Reducer<MeetingFooterState, MeetingFooterAction, Void>{ _, _, _ in .none },
environment: ())
store.assert(
.send(.skipSpeaker) { state in
// No change to the `state` here
}
)
}
} Thanks for any thoughts on this! Best, PS:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I'd say so! The assertion that state doesn't change could be beneficial down the line. If the child ever changes its logic to do something internally, the test would begin to fail.
Not at all! It's a pattern similar to the delegate pattern. The child provides delegate actions that a parent can listen to. In our projects we even like to group all delegate actions into a single |
Beta Was this translation helpful? Give feedback.
I'd say so! The assertion that state doesn't change could be beneficial down the line. If the child ever changes its logic to do something internally, the test would begin to fail.
Not at all! It's a pattern similar to the delegate pattern. The child provides delegate actions that a parent can listen to. In our projects we even like to group all delegate actions into a single
case delegate
😄