Forem: David

Unit testing with Mockk tweaks and tricks part1

David — Wed, 09 Mar 2022 18:17:17 +0000

Overview

This post is meant to be for some tweaks and tricks in MockK like testing Private methods with their return value and livedata changes. It's not an introduction to the library. Actually the documentation is great for exploring the library.

Introduction

Why should we write code to test an already implemented feature, when we can use that time in implementing another feature ?

Many developers seem to underestimate the value added by unit and integration test code.

Actually I believe the code written in Software testing is of more value on the long run than that of the production, because as long as project is not dead and is used, there will always be new feature requests and new bugs emerge that needs to be fixed.

How will we make sure that the code added didn't make other issues in the already working features?

Software testing is needed for the survival of the production code. Manual testing made by us will never be enough to verify that every thing is working fine.

And of course the testing code changes over time, and because of that you have to write your tests in a clean way, to be able to change them easily.

The importance of Mocking

We use mocking in many cases:

mocking the dependencies needed by a class to test it separately as a black box
Make our tests run faster by mocking databases or server responses instead of using real ones, and many more.

Mockk

MockK is one of the best mocking libraries for Kotlin, it supports coroutines and has many cool features.

No more talk and let's see a practical example.

Here is an example LoginViewModel class that we will test through the post



class LoginVM constructor(
    private val loginUseCase: ILoginUseCase,
) {

    fun login(userIdentifier: String, password: String): Boolean {
        return if (isFormValid(userIdentifier, password)) {
            loginValidatedUser(userIdentifier, password)
        } else false
    }


    private fun isFormValid(userIdentifier: String, password: String): Boolean {
        return if (isFieldEmpty(userIdentifier)) {
            false
        } else if (!isInputNumerical(userIdentifier) && !isEmailValid(userIdentifier)) {
            false
        } else if (isInputNumerical(userIdentifier) && !isPhoneNumberValid(userIdentifier)) {
            false
        } else if (isFieldEmpty(password)) {
            false
        } else isPasswordValid(password)
    }

    private fun loginValidatedUser(userIdentifier: String, password: String): Boolean {
        return loginUseCase.login(userIdentifier, password)
    }
}

This class has one public method which is login that takes userIdentifier and password and then it checks if they are valid or not and depending on that it will call the loginUseCase object.

And that's the ILoginUseCase interface:



interface ILoginUseCase {
    fun login(userIdentifier: String, password: String): Boolean
}

To test this class we will need to mock the login use case which is passed in the constructor, first.
And that's how it's done in MockK:



val loginUseCase = mockk<ILoginUseCase>()
val viewModel = LoginVM(loginUseCase)

Testing a mocked object is not called at all

Now let's call the login method in the LoginVM with invalid userIdentifier and check if the loginUseCase is not called at all



val result = viewModel.login("", "")
verify { loginUseCase wasNot Called } //used only to check the whole mocked object

Testing that a method is not called

That's how to see if a specific method is not called at all:



 verify(exactly = 0) {
    loginUseCase.login(any(),any() )
 } //used to detect if a method was not called in the mocked object

any() is used to represent any argument, if we want to check if the method with a specific argument, we will remove any() and pass that value instead.

Mocking a method

Now if we provided a valid userIdentifier and password to the login method in the LoginVM we will get an exception for not defining the behavior of the login method in the use case

So let's make this method return false at first and then true
and always remember, the last returned value will remain the answer of that method if it's called more than twice.



val loginUseCase = mockk<ILoginUseCase>()
every { loginUseCase.login(any(), any()) } returns false andThen true

val viewModel = LoginVM(loginUseCase)
//return false
var result = viewModel.login("david@gmail.com", "Test@123")
assertEquals(false, result)

 //return true
result = viewModel.login("david@gmail.com", "Test@123")
assertEquals(true, result)

Custom Mocking

We can return a specific response depending on the passed arguments and here's how:



val loginUseCase = mockk<ILoginUseCase>()
every { loginUseCase.login(any(), any()) } answers {
  val email: String = arg(0)
  val password: String = arg(1)
  email == "david@gmail.com" && password == "Test@123"
}
val viewModel = LoginVM(loginUseCase)
assertEquals(true, viewModel.login("david@gmail.com", "Test@123"))
assertEquals(false, viewModel.login("davi@gmail.com", "Test@123"))
assertEquals(false, viewModel.login("david@gmail.com", "Test@23"))

Testing private methods

Even though I don't recommend it, the need to test private methods could be a code smell that you need to refactor the logic inside that method into a separate testable class and leave that method private.
But Yes
We will use spyk provided by MockK which is used to create a real object that we can spy on and create some mocked behavior for specific methods of that object.
Since MockK uses reflection to test the private methods, we will need to pass the method name and the arguments types as shown in the verify block.



val viewModel = spyk(LoginVM(loginUseCase), recordPrivateCalls = true)

verify {  viewModel["isFormValid"](any<String>(), any<String>())}

Testing return of private methods:

Sadly the library doesn't support testing the return of private methods in a direct way, but it has many features that we can use them to test this value.

Let's try to test isFormValid private method in the view model class.
The idea I came up with is to use every block provided by MockK DSL to mock the behavior of that private method and call the actual method in that block using callOriginal() provided by MockK to record the return value in a separate value, and return that value in the defined mocking behavior so that nothing differs from the behavior of the original method



val loginUseCase = mockk<ILoginUseCase>()
val viewModel = spyk(LoginVM(loginUseCase), recordPrivateCalls = true)
var returnValue: Boolean? = null
every { viewModel["isFormValid"](any<String>(), any<String>()) } answers {
    returnValue = callOriginal() as Boolean
    return@answers returnValue
}
viewModel.login("david", "123")
assertEquals(false, returnValue!!)

Capturing the arguments passed to a mocked method

We can always get the passed argument to our mocked method to make some complex test cases.
Actually I find it an important technique that helped me a lot to capture the changes in live data or any observable object.

Let's see example first, we will try to capture the passed email to the login method:



val loginUseCase = mockk<ILoginUseCase>(relaxed = true)
val viewModel = LoginVM(loginUseCase)
val captureEmailArg = mutableListOf<String>()

viewModel.login("david@gmail.com", "Test@123")
viewModel.login("davi@gmail.com", "Test@123")
viewModel.login("dav@gmail.com", "Test@123")

verify {loginUseCase.login(capture(captureEmailArg), any())}
println(captureEmailArg)

The printed list is [david@gmail.com, davi@gmail.com, dav@gmail.com]

But how to use this to test the changes in a livedata and not only the most recent value?
The idea is simple, we will mock an Observer object and pass it to the liveData object and when this liveData changes it will call the onChanged method of the observer object passing the new state as an argument, and that's what we need this argument is the new value of the live data that we need to capture similar to the example above
Here's the code for observing a livedata that holds a String



val mockedObserver :Observer<String> = mockk(relaxed = true)
val changes = mutableListOf<String>()
every { mockedObserver.onChanged(capture(changes)) }
val liveData = MutableLiveData("")
liveData.observeForever(mockedObserver)

Now the changes will contain all the changes happened in the live data.

Here is a repo with most of the code used.

Thanks for reading so far, if you have an extra trick or tip for using this awesome library you can share it with us in the comments ^_^

How to use Multiple Bottom-sheets in Android Compose

David — Fri, 07 May 2021 12:53:36 +0000

After trying to refactor my project from the normal view system to Android Compose, I can really feel the difference between them.

I feel Android Compose will for sure become the default way to build UI in native android, but it still have a lot of cons that Google engineers are trying to solve but till then, I am gonna write on how to solve one of them in this post and it is how to have multiple bottom-sheets in the same app.

After reading this article you will easily build multiple bottom sheets as shown below.

First before reading please be careful that this post applies to compose version 1.0.0-beta05.
and is definitely related to these issues:

If these two issues are not solved yet you can continue reading my post, if any of them are solved and it will change the way to support multiple bottom-sheets, I will write another post.

1- Now Let's start by defining the bottom sheets that we are gonna use in our application

sealed class BottomSheetScreen() {
    object Screen1: BottomSheetScreen()
    object Screen2: BottomSheetScreen()
    class Screen3(val argument:String):BottomSheetScreen()
}

2- We will have a mutable state of our current sheet

@Composable
private fun MainLayout() {
  var currentBottomSheet: BottomSheetScreen? by remember{
        mutableStateOf(null)
    }
}

3- We will use BottomSheetScaffold to handle opening and closing the bottom sheet

   val scaffoldState = rememberBottomSheetScaffoldState()
   BottomSheetScaffold(sheetPeekHeight = 0.dp, scaffoldState = scaffoldState,
        sheetShape = BottomSheetShape,
        sheetContent = {
           currentBottomSheet?.let { currentSheet ->
                SheetLayout(currentSheet,closeSheet)
            }
        }) { paddingValues ->
            Box(Modifier.padding(paddingValues)){
                MainContent(openSheet)
            }
    }

4- Now, We will define two lambdas for opening and closing the bottom sheet

val closeSheet: () -> Unit = {
        scope.launch {
            scaffoldState.bottomSheetState.collapse()

        }
    }


    val openSheet: (BottomSheetScreen) -> Unit = {
        currentBottomSheet = it
        scope.launch { scaffoldState.bottomSheetState.expand() }

    }
    // to set the current sheet to null when the bottom sheet closes
    if(scaffoldState.bottomSheetState.isCollapsed)
        currentBottomSheet = null

Summing it up, our code should be similar to that

@OptIn(ExperimentalMaterialApi::class)
@Composable
private fun MainLayout() {
    val scope = rememberCoroutineScope()
    val scaffoldState = rememberBottomSheetScaffoldState()
    var currentBottomSheet: BottomSheetScreen? by remember{
        mutableStateOf(null)
    }

    val closeSheet: () -> Unit = {
        scope.launch {
            scaffoldState.bottomSheetState.collapse()
        }
    }


    val openSheet: (BottomSheetScreen) -> Unit = {
        currentBottomSheet = it
        scope.launch { scaffoldState.bottomSheetState.expand() }

    }
  if(scaffoldState.bottomSheetState.isCollapsed)
        currentBottomSheet = null

    BottomSheetScaffold(sheetPeekHeight = 0.dp, scaffoldState = scaffoldState,
        sheetShape = BottomSheetShape,
        sheetContent = {
          currentBottomSheet?.let { currentSheet ->
                SheetLayout(currentSheet,closeSheet)
            }
        }) { paddingValues ->
            Box(Modifier.padding(paddingValues)){
                MainContent(openSheet)
            }
    }
}

5- Now we will define our SheetLayout, as we can see from the above code that it takes two parameters

The current bottom sheet
The closeSheet lambda, because if we want to have a button to close the sheet

It should be similar to that

@Composable
fun SheetLayout(currentScreen: BottomSheetScreen,onCloseBottomSheet :()->Unit) {
    BottomSheetWithCloseDialog(onCloseBottomSheet){
        when(currentScreen){
            BottomSheetScreen.Screen1 -> Screen1()
            BottomSheetScreen.Screen2 -> Screen2()
            is BottomSheetScreen.Screen3 -> Screen3(argument = currentScreen.argument)
        }

    }
}

6- Finally last step we define MainContent composable function that takes openSheet as a parameter

@Composable
fun MainContent(openSheet: (BottomSheetScreen) -> Unit) {
    Column(Modifier.fillMaxSize(),verticalArrangement = Arrangement.SpaceEvenly,horizontalAlignment = Alignment.CenterHorizontally) {
        Text(text = "This is Main Content")
        Button(onClick = { openSheet(BottomSheetScreen.Screen1) }) {
            Text(text = "Open bottom sheet 1")
        }

        Button(onClick = { openSheet(BottomSheetScreen.Screen2) }) {
            Text(text = "Open bottom sheet 2")
        }
        Button(onClick = { openSheet(BottomSheetScreen.Screen3("this is an argument")) }) {
            Text(text = "Open bottom sheet 2")
        }
    }
}

NB: Here is the whole project used in the Demo on Github

Thanks for reading 🐱‍🏍