Good news for Android devs using Kotest work in progress on

Question

Good news for Android devs using Kotest work in progress on LiveData assertions and extension listener smile

Javier · Answer

Is there something for Flow Actually I was using Turbine by Square

wasyl · Answer

We ve used this one for some time now basically translated the JUnit listener ``` AutoScan object InstantTaskExecutorListener TestListener override suspend fun prepareSpec kclass KClass lt out Spec gt 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 lt out Spec gt results Map lt TestCase TestResult gt ArchTaskExecutor getInstance setDelegate null ``` Is the new one better somehow

LeoColman · Answer

Hey < alexfacciorusso> I also had a version of that in one of my projects if you want to take a look

LeoColman · Answer

alexfacciorusso · Answer

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 smile 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

wasyl · Answer

So sadly this also breaks parallelism of these tests disappointed Thought maybe there s some clever way of working around the poor ArchTaskExecutor design disappointed

alexfacciorusso · Answer

yeah indeed It might be an exercise for the future for now let s introduce it for everyone and then enhance if possible

alexfacciorusso · Answer

Here it is a WIP PR open for suggestions <https github com kotest kotest pull 1783>

alexfacciorusso · Answer

< 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

Javier · Answer

< alexfacciorusso>

alexfacciorusso · Answer

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

alexfacciorusso · Answer

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 ```liveData testing it TestObserver gt 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

alexfacciorusso · Answer

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

Javier · Answer

That is similar a how Turbine works with Flow

alexfacciorusso · Answer

Yes indeed it is

Javier · Answer

```flowOf one two test assertEquals one expectItem assertEquals two expectItem expectComplete ```

alexfacciorusso · Answer

And in that case we might keep the same syntax for both the LiveData and Flow Kotest testing

sam · Answer

Is this flows as in kotlinx flows or something android related

alexfacciorusso · Answer

the first one

sam · Answer

And What s the limitations of turbine

sam · Answer

And what s the tldr for live data for non android devs

Javier · Answer

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

alexfacciorusso · Answer

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

alexfacciorusso · Answer

< sam> ^

sam · Answer

So it s like an Observable from the jdk

alexfacciorusso · Answer

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

sam · Answer

Ok cool thanks

Javier · Answer

For flow there is StateFlow

Javier · Answer

alexfacciorusso · Answer

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

sam · Answer

Right makes sense

alexfacciorusso · Answer

and maybe even better build a shared matchers API to cover that kind of cases

sam · Answer

I always liked the akka actors testkit That had an api for things like expect message and so on

sam · Answer

Fits in with the general theme of this library being scala inspired smiley

alexfacciorusso · Answer

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

sam · Answer

Ok

alexfacciorusso · Answer

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

alexfacciorusso · Answer

< sam> < LeoColman> ^

alexfacciorusso · Answer

sam · Answer

Nice I m on holiday myself until tomorrow so I ll review then