https://kotlinlang.org logo
Join Slack
Powered by
Good news for Android devs using Kotest: work in p...
# kotest
a
Good news for Android devs using Kotest: work in progress on LiveData assertions and extension listener! 😄
❤️ 1
🎉 1
j
Is there something for Flow? Actually I was using Turbine by Square
w
We’ve used this one for some time now, basically translated the JUnit listener:
Copy code
@AutoScan
object InstantTaskExecutorListener : TestListener {
    override suspend fun prepareSpec(kclass: KClass<out Spec>) {
        ArchTaskExecutor.getInstance().setDelegate(object : TaskExecutor() {
            override fun executeOnDiskIO(runnable: Runnable) {
                runnable.run()
            }
            override fun postToMainThread(runnable: Runnable) {
                runnable.run()
            }
            override fun isMainThread(): Boolean {
                return true
            }
        })
    }
    override suspend fun finalizeSpec(kclass: KClass<out Spec>, results: Map<TestCase, TestResult>) {
        ArchTaskExecutor.getInstance().setDelegate(null)
    }
}
Is the new one better somehow?
l
Hey, @alexfacciorusso!I also had a version of that in one of my projects, if you want to take a look
a
Yep my implementation is basically the same as yours @LeoColman @wasyl, but I've created an extension module in the actual Kotest project so it'll be easier and more standard to have it included in other projects without the need of copy-pasting code! 😄 I think the most important thing tho is the set of matchers. I'll make a draft PR soon so the WIP will be transparent
w
So, sadly, this also breaks parallelism of these tests 😞 Thought maybe there’s some clever way of working around the poor ArchTaskExecutor design 😞
a
yeah indeed. It might be an exercise for the future, for now let's introduce it for everyone and then enhance if possible
Here it is a WIP PR, open for suggestions! https://github.com/kotest/kotest/pull/1783
@Javier could you please create an issue on GitHub? I will be happy to have a look at the implementation of Flow matchers after I’ve finished the LiveData ones!
j
a
I was thinking if it might make more sense to be able to create a test observer for the LiveData and then apply matchers on it, instead of applying matchers on the livedata directly
E.g. I was thinking of borrowing the 
TestObserver
from https://github.com/jraska/livedata-testing, rewriting it completely in Kotlin and exposing that class in the LiveData matcher, so that we can do things like:
Copy code
liveData.testing { it: TestObserver ->
  it shouldHaveValue 1
  someOtherAction()

  it shouldHaveHistory listOf(1,2)
}
that might be one idea, but I need inputs on this, what do we would prefer
so that the matchers would be built on the 
TestObserver
class instead than on the 
LiveData
directly, since doing so instead would limit the possibilities we have to test, for example, the history of the livedata values
j
That is similar a how Turbine works with Flow
a
Yes indeed it is
j
Copy code
flowOf("one", "two").test {
  assertEquals("one", expectItem())
  assertEquals("two", expectItem())
  expectComplete()
}
a
And in that case we might keep the same syntax for both the LiveData and Flow Kotest testing
s
Is this flows as in kotlinx flows or something android related
a
the first one
s
And What's the limitations of turbine
And what's the tldr for live data for non android devs
j
I am using turbine + kotest without problems, but if Kotest add some framework to test livedata, I think it has sense to have one for flow
a
I never used really turbine, probably @Javier can talk about it, but what I was thinking is that we should keep the test styles similar for an eventual Flow and LiveData matchers with Kotest. Do we have any other similar concept of something to observe and then to test its value? LiveData is very much like a 
BehaviourSubject
in Rx if you’re familiar with it, or in general is a class notifying an observer that something in it has changed, and usually keeps its latest value in memory
@sam ^
s
So it's like an Observable from the jdk
a
in a very detached way, in the sense that it has many more Android related stuff like lifecycle and mapping etc, but in a way it might be seen similar to an observable, yes
s
Ok cool thanks
j
For flow there is StateFlow
a
the idea is we might have to introduce a new concept for this kind of observable-thingies like Kotlin Flows, Android LiveData etc, and keep the test style similar, like agree on a common syntax
s
Right makes sense
a
and maybe even better build a shared matchers API to cover that kind of cases
s
I always liked the akka actors testkit. That had an api for things like expect message and so on.
Fits in with the general theme of this library being scala inspired 😃
a
Fair enough, I’ll have a look later on at that and see if we can come up with a common interface to be used for that kind of tests
s
Ok
a
I consider the PR done (sorry for the delay but I've gone for a holiday and I've been stuck with a heavy project at work). The only thing that needs to be done is the documentation, but I will wait for the PR to be "code-accepted" in order to start writing the documentation, or even we could want to merge the code first and then I can create a separate PR for the documentation to avoid noise
@sam @LeoColman ^
s
Nice. I'm on holiday myself until tomorrow so I'll review then.
6 Views
Open in Slack
PreviousNext
Powered by