Skip to content
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

Features testing. #110

Open
linyaDev opened this issue Sep 9, 2019 · 3 comments
Open

Features testing. #110

linyaDev opened this issue Sep 9, 2019 · 3 comments
Labels
question Further information is requested

Comments

@linyaDev
Copy link

linyaDev commented Sep 9, 2019

Hi guys. Do you have any examples, best practices how you tests yours features?

@zsoltk zsoltk added the question Further information is requested label Sep 12, 2019
@zsoltk
Copy link
Contributor

zsoltk commented Sep 12, 2019

You can unit test the individual pieces if needed (Reducer, Actor). You can also unit test the whole Feature by setting it up with some specific initial state, feeding it a Wish, and checking if new state is as expected / expected News are triggered.

@THEAccess
Copy link

I'm trying to test my feature which initially uses a Bootstrapper and PostProcessor to fetch data from a remote database. This should emit the result directly after the initial state. In my test I use a fake implementation which returns fake data immediately.
However, even if I use TestObserver#await and Test Scheduler, the test always fails because the reducer invocation doesn't happen before the test is terminated.

Are there any best practices to fix this issue?

`@Test
fun fetches_messsages() = runBlocking{
val t = TestObserver()
homeFeature.subscribe(t)

    t.await(3L, TimeUnit.SECONDS)
    t.assertValueCount(2)
}

`

The rule i ues:
`class TrampolineSchedulerRule : TestRule {

val testScheduler = TestScheduler()

override fun apply(base: Statement, d: Description): Statement {
    return object : Statement() {

        override fun evaluate() {
            RxJavaPlugins.setIoSchedulerHandler { Schedulers.trampoline() }
            RxJavaPlugins.setComputationSchedulerHandler { Schedulers.trampoline() }
            RxJavaPlugins.setNewThreadSchedulerHandler { Schedulers.trampoline() }
            RxAndroidPlugins.setInitMainThreadSchedulerHandler { testScheduler }

            try {
                base.evaluate()
            } finally {
                RxJavaPlugins.reset()
                RxAndroidPlugins.reset()
            }
        }
    }
}

}`

@zsoltk
Copy link
Contributor

zsoltk commented Sep 27, 2019

@THEAccess If you would test the actual value, and not just the value count, you would probably find that the single value you get is not the Feature's initial state, but the next one: the state which is the result of completing your Bootstrapper action.

This is because initial state is fired upon Feature creation immediately, and Bootstrapper is also invoked immediately. By the time you subscribe to your Feature, its latest state is the one that is reflected on the receiving end (as if it was a BehaviorSubject).

And, because there are no further actions to execute, no matter how long of a delay you put into place, you're not gonna get another one.

I suggest you read:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants