-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Best practices for mocking dependencies? #34
Comments
Interior mutability is one option, however this leads to a lot of extra code to deal with the requirement that everything captured in the async state methods must be |
Ended up using |
I'm open to adding some way to get a mutable reference to the state machine's internal data, but we probably shouldn't use An alternative would be to provide methods such as |
Problem: Mutable access to `Inner` is required for ergonomic unit testing. Solution: Add `inner` and `inner_mut` to: - `awaitable::state_machine{UninitializedStateMachine, InitializedStateMachine}` - `blocking::state_machine{UninitializedStateMachine, InitializedStateMachine}` Mark the methods as `unsafe` for the case of an `InitializedStateMachine` to force users to think critically about mutating in thise case. Testing: `cargo test` Issue: mdeloof#34
Problem: Mutable access to `Inner` is required for ergonomic unit testing. Solution: Add `inner` and `inner_mut` to: - `awaitable::state_machine{UninitializedStateMachine, InitializedStateMachine}` - `blocking::state_machine{UninitializedStateMachine, InitializedStateMachine}` Mark the methods as `unsafe` for the case of an `InitializedStateMachine` to force users to think critically about mutating in thise case. Testing: `cargo test` Issue: mdeloof#34
Problem: Mutable access to `Inner` is required for ergonomic unit testing. Solution: Add `inner` and `inner_mut` to: - `awaitable::state_machine{UninitializedStateMachine, InitializedStateMachine}` - `blocking::state_machine{UninitializedStateMachine, InitializedStateMachine}` Mark the methods as `unsafe` for the case of an `InitializedStateMachine` to force users to think critically about mutating in thise case. Testing: `cargo test` Issue: mdeloof#34
I'm really enjoying
statig
but am facing challenges with unit testing state transitions. My goal is to:I'm using
serde
for state initialization (as suggested in #25), but this prevents me from setting mock expectations beforehand. See a reproducible example here: #33.The issue is that neither
UninitializedStateMachine<M>
norInitializedStateMachine<M>
implementcore::ops::DerefMut
, preventing mutable access for mock configuration before initialization.A potential solution is implementing
DerefMut
(#32), but I'm unsure if providing mutable access at all times is ideal. Perhaps implementing it only forUninitializedStateMachine<M>
would be better? I'm open to suggestions.The text was updated successfully, but these errors were encountered: