Open charypar opened 9 months ago
Further thoughts:
resolve_and_update
should have flat_map
-like semantics - all the events sent may produce effect requests, and the total set of them should come back. Having the batches might also be useful, the caller can always .flatten()
.let else
seem quite a natural way to do the filtering, since it's often useful to do a let binding of the operation for further assertionsI would like some helper methods on Update
:
fn assert_one_event(self) -> Event;
fn assert_one_effect(self) -> Effect;
These would check that there is exactly one event/effect (and no effects/events) and return it. Names bikeshedable.
I would like the type that you get from app.resolve(..)
to be something other than Update
(Resolve
?). I am always getting confused about where the update comes from and where it should go.
Update::settled() -> bool
, which checks that events and effects are both empty would be handy.
This is a list of nice to have APIs on the AppTester to make tests a little bit verbose in common cases. I'll be updating this issue as I think of them. We can also discuss them as we go, and when there's a few of them, I'll open a PR implementing them.
tester.resolve_and_update
- resolves an effect and immediately sends any resulting eventsupdate.filter_effects(Effect::into_x)
- shorthand forupdate.into_effects().filter_map(Effect::into_x)
update.first_effect(Effect::into_x)
- shorthand forupdate.into_effects().filter_map(Effect::into_x).next().ok_or(some_error)
macro combining the effect finding shorthand with
assert_let
like behaviour on the operation the effect carries, if possible. It's quite common to pull data out of the requests, while also holding onto the request in order to resolve it.E.g. something like