Photo by Wolfgang Hasselmann on Unsplash

🙋🏻 Why Local Unit Tests?

Local unit tests with JUnit 5 can be run quickly prior to writing a feature and regularly to ensure code quality and mitigate regressions of features’ business logic. These tests do not require dependencies on the Android system. This covers the majority of code for most apps making it a great first step for testing. These local unit tests can be expanded into integration tests for more thorough testing of the data layer, such as network requests and local databases, and for instrumented tests including the UI components.

🥼 Built-in testing

Once modularized properly, the business logic model, in this case Android’s ViewModel component, and the view interface contract used in production are also used for local unit tests without modification to test the given intents that the model uses to generate the expected view states.

MVI defines the intents driven by the Android system and user actions that the model processes to create the view states. Because the ViewModel business logic component observes the intent actions and creates the final persisted data of each view state, a local unit test makes use of the existing ViewModel and view interface contract.

🏎️ More efficient code

Creating intents and view states with MVI reduced the test code by more than 50% compared to the previous implementation using the UDF and emitting many streams of data simultaneously.

100% of FeedViewModel.kt is covered in local unit tests in Coinverse with MVI comprising 306 lines of code in the FeedViewTest.kt class, compared to 753 lines of code across four test classes covering mostly the same code prior to the MVI refactor. In the pre-MVI pattern, UDF was implemented to separate the view, business logic, and data layer. However, many sources of data were emitted from the ViewModel to the View making the tests harder to read, write, and created issues with the order of data being emitted. By knowing exactly what view state should be emitted based on each intent with MVI, it makes the tests more reliable, quicker to build, and more concise.

FeedViewModel.kt Test Coverage

Implement

Photo by Fredrik Ivansson on Unsplash

📚 Libraries — Step 1 of 5

• JUnit 5 with parameterized tests — Reuse the tests with a stream of many test cases.
• MockK — Creates components involving the Android system or classes handling data requests like a repository or database, returning data that would be expected to be returned in the loading, success, and error states.
• Kotlin coroutines — Initiate intent actions and observe view state changes with StateFlow.
• AssertJ — Evaluates the actual vs. expected states.

build.gradle (Module)

build.gradle (App)

Releases/Versions

• JUnit 5
• MockK
• Coroutines
• AssertJ

💼 ViewModel — Step 2 of 5

A. Define how components are injected

In order to use the same business logic in production and testing, all components that rely on the Android system or data requests are injected into the ViewModel so that test instances can be used in the local unit tests.

See: Android Model-View-Intent with Kotlin Flow > Model — ViewModel > ‘CoroutineScope and CoroutineDispatcher’ and ‘Dagger 2 Dependency Injection for ViewModels with AssistedInject’

FeedViewModel.kt

1. CoroutineScope — With the custom extension function,getViewModelScope, for production no scope is injected and the Android’s viewModelScope is used by default. In testing the TestCoroutineScope is explicitly injected.
2. FeedRepository — Data requests made to the network and local database will be mocked requiring a test instance of the repository to be injected.

B. Create the test components to inject

FeedViewTestExtension.kt

1. TestCoroutineDispatcher and TestCoroutineScope are created in a JUnit 5 test extension. The dispatcher is necessary to ensure coroutines run on a test thread and the scope defines the lifecycle that the coroutines runs within.
2. The ArchTaskExecutor is required for LiveData to return the PagedList.

See: Android Unidirectional Data Flow — Local Unit Testing > 1a. Configuration — Extensions

FeedViewTest.kt

1. The mock repository is initialized and passed into the ViewModel along with the TestCoroutineScope created in FeedViewTestExtension.kt above.
2. The repository method getMainFeedNetwork's response is mocked to return test data. In the full sample code this emits a Flow of PagedListdata. With the Paging 3 library this can be simplified removing the dependency to mock LiveData asPagedList and return a PagingDataresponse with Kotlin coroutines. See StackOverflow for Paging 2: Convert List Into PagedList With Mock DataSource.Factory
3. The FeedViewTestCaseStream is a Stream.of(...) FeedViewTestCase defined in a data class and represents different scenarios such as loading, success, and error states. The stream is passed into the test making the test reusable for all of the states defined.

🌉 Interface — Step 3 of 5

Bind the view interface contract to the ViewModel

1. The majority of logic tested is defined by implementing the view interface and binding it to the ViewModel. The interface represents the intent/actions sent from the view to the ViewModel, and the view states rendered by the ViewModel back to the view. See: Android Model-View-Intent with Kotlin Flow > Intent — View Interface
2. The view’s StateFlow intents are defined in FeedViewIntent for organizational purposes. See: Android Model-View-Intent with Kotlin Flow > View — Activity/Fragment
3. The test view interface observes emissions from the intent Flows and the test view interface renders a view state sealed class as it would in production.

FeedViewTest.kt

🖼️ Intents and View States — Step 4 of 5

1. Call the intents/actions that initiate the business logic to generate a view state, in this case, loadFromNetwork intent is emitting a true value which initiates the FeedViewModel to create the Feed state. Then, observe that the actual view state of type Feed matches the expected state.
2. isEqualToComparingFieldByField is used to compare the properties of the actual and observed Feed view state emitted. Feed is a class rather than a data class so that each instance of Feed has a unique hash code and can be properly emitted by the model.

FeedViewTest.kt

🔬 Verify and Confirm Method Calls — Step 5 of 5

1. The MockK verification coVerify confirms that the method getMainFeedNetwork is called within the test.
2. confirmVerified checks that all method calls in the test are verified/expected to be called.

See: Android Unidirectional Data Flow — Local Unit Testing > 5. Verify Tests

FeedViewTest.kt

Summary

Photo by Michael D on Unsplash