Add ScriptableStateStore #88
Conversation
BenSchwab
force-pushed
the
bschwab--testing-changes
branch
from
72c40b2 to
c477152
Compare
BenSchwab
requested review from
gpeal,
hellohuanlin and
elihart
and removed request for
gpeal
| * how your UI code reacts to different ViewModel states. This is not as useful for unit testing your view model, | ||
| * as business logic in state reducers will not be used. | ||
| */ | ||
| class ScriptableMvRxStateStore<S : Any>(initialState: S) : MvRxStateStore<S> { |
There was a problem hiding this comment.
should this be internal?
There was a problem hiding this comment.
I think it's great for other people to use this for testing
| // No-op set the state via next | ||
| } | ||
|
|
||
| fun next(state: S) = subject.onNext(state) |
There was a problem hiding this comment.
is it possible to use the real store, and call set { newState }, rather than next(newState) here?
There was a problem hiding this comment.
set on the real store is asynchronous, we need this to be synchronous for tests. Also, we want set to be a no-op so that observables in the real viewmodel don't override our test state
There was a problem hiding this comment.
i think all tests run synchronously
There was a problem hiding this comment.
@hellohuanlin This is for use in integration tests, specifically screenshot testing. Unit tests only run synchronously because we override RxJava schedulers via plugins, which are global settings, and not something we would want to change in an integration test as it would effect non-mvrx code.
| * how your UI code reacts to different ViewModel states. This is not as useful for unit testing your view model, | ||
| * as business logic in state reducers will not be used. | ||
| */ | ||
| class ScriptableMvRxStateStore<S : Any>(initialState: S) : MvRxStateStore<S> { |
There was a problem hiding this comment.
I think it's great for other people to use this for testing
| // No-op set the state via next | ||
| } | ||
|
|
||
| fun next(state: S) = subject.onNext(state) |
There was a problem hiding this comment.
set on the real store is asynchronous, we need this to be synchronous for tests. Also, we want set to be a no-op so that observables in the real viewmodel don't override our test state
|
|
||
| fun next(state: S) = subject.onNext(state) | ||
|
|
||
| override fun isDisposed() = false |
There was a problem hiding this comment.
it might be worth tracking this correctly, since tests will deal with lifecycle and this may need to be accurate for whatever reason
This builds upon #81, but uses an interface instead of a companion object to manage mocking.
The motivation behind this is to provide some infrastructure for UI tests which are powered by MvRx. In these tests, you just want to set a state and asssert that the UI is what you expect. To achieve this a state store which ignores standard calls to
setState, but can be scripted via a separate method appears to be effective.