You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am curious in how community implements and tests the recursive actions. I have a spec where I need to refresh the data every N minutes. I opted in for a recursive action invocation using a deferred effect. How do I test that? Is having a failure condition (and modeling environment accordingly) the only option?
E.g.:
struct State: Equatable {
var nextRefresh: TimeInterval
}
enum Action: Equatable {
case schedule
case refresh
case refreshCompleted(Response)
case refreshFailed(URLError)
}
struct Environment {
var scheduler: AnySchedulerOf<DispatchQueue>
var refresh: () -> Effect<Response,URLError>
}
let reducer = Reducer<State,Action> { state,action,env in
switch action {
case .schedule:
// calculate the delay based on Date() and state.nextRefresh
return Effect(value: .refresh).deferred(for: Nminutes, on: env.scheduler)
case .refresh:
return env.refresh().catchToEffect {
switch $0 {
case .success(let resposne): return Effect(value: .refreshCompleted(response))
case .failure(let error): return Effect(value: .refreshFailed(error)
}
}
case .refreshCompleted(let response):
state.nextRefresh = calculateNextRefresh(after: response)
return Effect(value: .schedule)
case .refreshFailed(let error):
break // stop the refresh in case of failure even though I would love to reshedule
}
}
It's pseudo-code, but I tried to replicate the actual one as close as possible with implementation omitted, but the concept clear. The testing would involve some number of .receive(.schedule), .receive(.refresh) and .receive(.refreshCompleted), but I'm pretty sure I would always get a failing test saying that I didn't handle a received action even with advancing test scheduler.
Another thing I am thinking of is timer publisher where a single action returns timer effect and then test that.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I am curious in how community implements and tests the recursive actions. I have a spec where I need to refresh the data every N minutes. I opted in for a recursive action invocation using a
deferred
effect. How do I test that? Is having a failure condition (and modeling environment accordingly) the only option?E.g.:
It's pseudo-code, but I tried to replicate the actual one as close as possible with implementation omitted, but the concept clear. The testing would involve some number of
.receive(.schedule)
,.receive(.refresh)
and.receive(.refreshCompleted)
, but I'm pretty sure I would always get a failing test saying that I didn't handle a received action even with advancing test scheduler.Another thing I am thinking of is timer publisher where a single action returns timer effect and then test that.
Beta Was this translation helpful? Give feedback.
All reactions