MVI in Kotlin Multiplatform — part 3 (3 of 3)

Arkadii Ivanov
Jul 28, 2020 · 11 min read

This is the concluding article in a series of three articles on MVI architectural pattern in Kotlin Multiplatform. In the previous two articles (part 1 and part 2) we reminded ourselves what MVI is, created the Kittens module for loading images of kittens, and integrated it into iOS and Android applications.

In this part, we are going to cover the Kittens module with unit and integration tests. We will learn about the current limitations of testing in Kotlin Multiplatform, how to overcome them and even make them work to our advantage.

The updated sample project is available in our GitHub:


  • allows you to check edge cases that can be difficult to catch manually;
  • prevents regression when adding new functionality, fixing bugs or refactoring;
  • forces code decomposition and structuring.

The last point, at first glance, may seem like a downside because decomposition takes time. However, it actually makes code more readable and so is beneficial in the long run.

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Kotlin Multiplatform empowers testing even more. It adds one very important point: each test is automatically executed against every supported target (platform). Therefore, if you support e.g. just Android and iOS, then you can actually multiply the number of tests you have by 2. And if at some point you support one more target, you are already covered because now you have x3 tests. Testing against all supported targets is especially important because there could be differences in code behaviour e.g. Kotlin/Native has a tricky memory model. JavaScript may sometimes also produce unexpected outcomes.

Before going any further it’s worth mentioning some limitations of testing in Kotlin Multiplatform. The biggest one is the lack of any real mocking framework for Kotlin/Native and Kotlin/JS. Whilst this can be perceived as a disadvantage, I actually consider it as a huge benefit. I struggled when I first started writing tests in Kotlin Multiplatform because I had to abstract every single dependency with an interface and write test implementations (fakes). This was time-consuming. But at some point, I realised that spending time on abstractions is an investment that results in a cleaner code. I noticed that any subsequent modifications of such code required less time. Why is that? Because the interaction of a class with its dependencies is not nailed (by mocks). In most cases, just updating test implementations is sufficient. There is no need to dive into each test method in order to update mocks. The result of this is that I no longer use mocks, even in normal Android development. For more on this point, I recommend the following article: Mocking is not practical — Use fakes (by Pravin Sonawane).

The plan

  • There is KittenStore — the core component of the module. It’s implementation KittenStoreImpl contains most of the module’s business logic. This is the first thing we are going to test.
  • KittenComponent — the facade of the module and the integration point of all the internal components. We will cover this component with integration tests.
  • KittenView — a public interface representing the UI, a dependency of the KittenComponent
  • KittenDataSource — an internal interface for low-level network access which has platform-specific implementations for iOS and Android

To better understand this, here is the UML diagram of the Kitten module:

So, the plan is:

  1. Test the KittenStore
    - Write test implementation of KittenStore.Parser
    - Write test implementation of KittenStore.Network
    - Write unit tests for KittenStoreImpl
  2. Test the KittenComponent
    - Write test implementation of KittenDataSource
    - Write test implementation of KittenView
    - Write integration tests for KittenComponent
  3. Run tests
  4. Provide some conclusions

Test the KittenStore

Test implementation of KittenStore.Network

Before actually writing the test implementation of the Network interface we first need to answer one important question. What data is returned by the server? The answer is: the server returns a random bunch of image URLs, and a different set of URLs is returned every time. In real life, JSON format is used but since we have the Parser abstraction we don’t care much about the format in unit tests. The real implementation may switch threads under the hood, so subscribers may become frozen in Kotlin/Native. It would be good to simulate this behaviour as well, just to make sure the code handles this correctly.

So, our test implementation of the Network needs to have the following features:

  • it should return a non-empty bunch of different strings on every request
  • responses should be encoded as String
  • encoding format should be common between the Network and the Parser
  • it should be possible to simulate network errors (the Maybe should just complete without response)
  • it should be possible to simulate invalid response format (so the Parser could fail)
  • it should be possible to simulate response delays, so we can verify loading stages
  • the test implementation itself should be freezable in Kotlin/Native, just in case.

Test implementation may look like this:

TestKittenStoreNetwork has storage of strings (just like the real server) and is able to generate them. On every request, the current list of strings is encoded into a single string. If the “images” property is null, then Maybe will just complete, which should be treated as an error.

We also used the TestScheduler. This has one important feature — it freezes all callbacks coming through it. So, the observeOn operator being used together with TestScheduler will be freezing the downstream as well as all data passing through it. Just like in real life. But at the same time, no multithreading will be involved, so it’s easy to test and there are no flaky tests.

The TestScheduler also has a special “manual processing” mode. This mode allows us to test network delays.

Test implementation of KittenStore.Parser

So, whatever is loaded from the network should be transformed to a list of URLs. Our Network just concatenates strings separated by the semicolon symbol ‘;’, so the same format should be used here.

Here is the test implementation:

Like with the Network it uses the TestScheduler to freeze subscribers and verify their compatibility with the Kotlin/Native memory model. Parsing errors are simulated if the input string is empty.

Unit tests for KittenStoreImpl

The first step is to instantiate our test implementations:

Then, the KittenStoreImpl uses the mainScheduler so the next step is to override it:

And now some tests. The KittenStoreImpl should load images once created. Which means a network request should be performed, its response should be parsed and the state should be updated with the result. Here is the test:

What we did:

  • we generated images in the Network
  • we created a new instance of the KittenStoreImpl
  • we verified that the state contains the proper list of strings.

Another case we need to cover is when KittenStore.Intent.Reload is received. In this instance the list should be reloaded from the network:

Here are the steps:

  • generate initial images
  • create the KittenStoreImpl
  • generate new images
  • send Intent.Reload
  • verify that the state contains new images.

And lastly, let’s test the following case, there should be isLoading flag set in the State while images are loading:

We enabled manual processing for the Network TestScheduler, so it won’t automatically process. This allows us to verify the State while the response is pending.

Test the KittenComponent

There are two dependencies: KittenDataSource and KittenView. We need test implementations for all of them before we can start testing.

This diagram shows demonstrating the data flow within the module:

Test implementation of KittenDataSource

TheCatAPI supports pagination so it’s worth noting that I added the related arguments. Apart from this, it is very similar to the KittenStore Network we implemented earlier. The only difference is that we have to use JSON format, since we are testing real code in integration. So, let’s just reuse ideas here:

As before, we are generating different lists of strings that are encoded into a JSON array on every request. If there are no images generated or if request arguments are invalid, the Maybe will just complete without a response.

The kotlinx.serialization library is used for JSON encoding. The real KittenStoreParser also uses it for decoding.

Test implementation for KittenView

It accepts Models and produces Events, so the test implementation is very simple:

We simply need to remember the last rendered Model as this will allow us to verify that the displayed Model is correct. We can also dispatch Events on behalf of the KittenView via its dispatch(Event) method.

Integration tests for KittenComponent

As before, let’s start with instantiating dependencies and the KittenComponent:

There are two schedulers currently used internally: mainScheduler and computationScheduler. We need to override them:

Now we can write some tests. Let’s test the happy case first, once created images are loaded and displayed:

This test is pretty similar to what we wrote in unit tests for the KittenStore. Except now the whole module is involved. Here are the steps:

  • generate image URLs in the TestKittenDataSource
  • create and start the KittenComponent
  • very that image URLs reached the TestKittenView.

Another interesting case is that images need to be reloaded when the KittenView produces the RefreshTriggered event:

Here are the steps described:

  • generate initial image URLs
  • create and start the KittenComponent
  • generate new image URLs
  • dispatch Event.RefreshTriggered on behalf of the KittenView
  • verify that new image URLs reached the TestKittenView.

Run tests

./gradlew :shared:kittens:build

It will compile the module and run all tests against all supported targets, both in android and iosX64.

Here is the Jacoco test coverage report:


  • the KittenStoreImpl — contains most of the business logic
  • the KittenStoreNetwork — responsible for high-level network requests
  • the KittenStoreParser — responsible for parsing network responses
  • all mappings and wirings.

The last point is very important and is possible thanks to MVI. The only responsibility of the UI is to render data and to dispatch events. All subscriptions and wirings are done inside the module. So, we can cover everything but rendering with common tests.

Such tests have the following advantages:

  • do not access platform-specific SDKs
  • executed very fast
  • not flaky
  • executed against all supported targets.

We were also able to verify the code for compatibility with the tricky Kotlin/Native memory model. This is very important as well because there is no compile-time safety. The code would just crash at runtime with exceptions that are difficult to debug.

I hope this will help you with your project. Thanks for reading my articles and don’t forget to follow me on Twitter!

If contributing to projects such as this is of interest to you, we are always looking for people to join the team. So, feel free to get in touch and find out more about joining the Bumble family!

MVI in Kotlin Multiplatform — Part 1
MVI in Kotlin Multiplatform — Part 2

Bonus exercise

Refactor the KittenDataSource

Objective: to move the endpoint URL generation logic from KittenDataSourceImpl (Android and iOS) to KittenStoreNetwork. You need to change the KittenDataSource interface in the following way:

Once you’ve done so you will need to update the tests. The only class you will need to touch is the TestKittenDataSource.

Add pagination

Finally, you will need to update some test implementations, fix one or two existing tests and then write some new ones to cover the pagination.

Bumble Tech

This is the Bumble tech team blog focused on technology and…

Arkadii Ivanov

Written by

Android Engineer @ Badoo

Bumble Tech

We’re the tech team behind social networking apps Bumble and Badoo. Our products help millions of people build meaningful connections around the world.

Arkadii Ivanov

Written by

Android Engineer @ Badoo

Bumble Tech

We’re the tech team behind social networking apps Bumble and Badoo. Our products help millions of people build meaningful connections around the world.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store