How to mock a suspend function on an existing mock object?

[Moes81]

I have mock A built and given to me. Now, I need to mock a suspend API to return a value foo.

Example:

@Inject lateinit var mockA: A // using dagger to provide mocks configured in a separate module.

@Test
fun test1() = runBlocking {
    // how do i mock a suspend method on mockA?
}

Originally posted by @andrewborba10 in #269 (comment)

[stawil15]

I know this comment will probably be considered unhelpful, but I recently spent a lot of time trying to do the same thing and I eventually came to the conclusion that, assuming no actual business logic is is taking place in your async block/function, I don't really get anything out of including it in my tests. Testing that a mocked class returns the mocked data that I mocked for it isn't actually useful.

That is to say, my suspend functions are only there to retrieve data (network calls) and I should focus on testing the function that contains the business logic for once those calls are returned.

Granted, if there is a way to do what you're asking for it can still be very useful and I want to know.

[Moes81]

I'm not sure if I can follow your argumentation, about not having actual business logic. Let me try to give you an example.
Let's consider A is actually called ARepo, which is a repository with the signature suspended fun getFoo(): Foo. My classUnderTest calls ARepo.getFoo(), takes that Foo object, does some checks and maps it to a child of the sealed class Bar. So, how would I mock different

sealed class Bar {
    object BarError: Bar()
    data class BarData(bar: object): Bar()
}

//In my test
private val aRepoMock: ARepo = mock()

private lateinit var classUnderTest: MyClass

@Before
fun setup() {
    classUnderTest = MyClass(aRepoMock)
}

@Test
fun getFoo_validObject_returnsBarData() = runBlocking {
    //how do I mock aRepoMock.getFoo() to return a valid object
   
    val result = classUnderTest.methodThatCallsGetFoo()
    assertTrue(result is BarData)
}

@Test
fun getFoo_invalidObject_returnsBarError() = runBlocking {
    //how do I mock aRepoMock.getFoo() to return an invalid object

    val result = classUnderTest.methodThatCallsGetFoo()
    assertTrue(result is BarError)
}

I hope this makes the use case a little clearer.

[bohsen]

@Moes81

@Test
fun getFoo_validObject_returnsBarData() = runBlocking {
    //how do I mock aRepoMock.getFoo() to return a valid object
    whenever(aRepoMock.getFoo()).thenReturn(BarData(42))
   
    val result = classUnderTest.methodThatCallsGetFoo()
    assertTrue(result is BarData)
}

@Test
fun getFoo_invalidObject_returnsBarError() = runBlocking {
    //how do I mock aRepoMock.getFoo() to return an invalid object
    whenever(aRepoMock.getFoo()).thenReturn(BarError())

    val result = classUnderTest.methodThatCallsGetFoo()
    assertTrue(result is BarError)
}

[Moes81]

@bohsen Thank you! I actually had it exactly this way, but I was getting compile errors. Let me double check on my project.

[matejdro]

There would still be a good reason to be able to provide suspend answers. For example you could have method suspend infinitely to mock server call that takes forever to complete.

[Hurricaaane]

With mockito-kotlin:2.1.0 :

@Test
fun getFoo_validObject_returnsBarData() = runBlocking {
    aRepoMock.stub {
        onBlocking { getFoo() }.doReturn(BarData(42))
    }
   
    val result = classUnderTest.methodThatCallsGetFoo()
    assertTrue(result is BarData)
}

I'm not entirely sure though.

[matejdro]

This still blocks the execution, not suspend. For example if you would do delay(2000) inside onBlocking, your test will freeze for two seconds instead of suspend.

[Moes81]

I personally don't care if the test would be blocked. My main issue is, that we have the convention to mock everything out for a positive execution. And within the individual methods, we adjust the existing mocks for different preconditions. With .stub {} (Thx @Hurricaaane for the hint!) this is now possible to do also for suspended functions. So, from my point of view, this can be closed.

[bohsen]

There would still be a good reason to be able to provide suspend answers. For example you could have method suspend infinitely to mock server call that takes forever to complete.

This would be an antipattern IMHO, unless I'm misunderstanding something (which btw. is very likely). For testing timeouts your code should throw Timeout Exceptions (or return sealed class representing a timeout). So just use doThrow() and your execution wont freeze.

For example if you would do delay(2000) inside onBlocking, your test will freeze for two seconds instead of suspend.

Beware that this is also a antipattern. delay() (and Thread.sleep()) should if possible be avoided in unit tests. I could accept it in an integration test or Instrumentation test, but never in a unit test. I would instead highly recommend using MockWebserver or TestContext (when #890 finally lands)

So, from my point of view, this can be closed.

@Moes81 You should close it then as you created the issue 😉

[matejdro]

For testing timeouts your code should throw Timeout Exceptions (or return sealed class representing a timeout). So just use doThrow() and your execution wont freeze

Yes, but you need to throw this exception somewhere and you need to test that this exception is thrown if there is no response for some time.

[bohsen]

@matejdro

Yes, but you need to throw this exception somewhere

In unit tests I would rely on the kotlinx.coroutine library maintainers having tested their code and just use doThrow(TimeoutCancelationException) if I was using the withTimeout() function. In my Integration/instrumentation tests I would use Mockwebserver with SocketPolicy set to NO_RESPONSE and confirm the correct behavior.

You need to test that this exception is thrown if there is no response for some time.

To me this would only apply if I where to implement my own timeout function, which I have never had the need to do. Would I ever have to do so, I would make the timeout property configurable or create my own Timer object, which I then would swap out with a fake implementation in my unit tests, with the ability to advance the time.

The Answer API IMO is for getting access to the arguments passed to mocks eg. testing asynchronous methods that have callbacks as parameters or in rare cases having synchronous methods return a specific value depending on the input.

But time and testing is difficult. That's why it's great that work is done on this in the coroutine library. This is where this problem should be solved.

[giangpham96]

There would still be a good reason to be able to provide suspend answers. For example you could have method suspend infinitely to mock server call that takes forever to complete.

I still think this is a valid point, here is an example, a class starts 1 job first, then starts another job which doesn't care about the result of first job, in this case, the first job should be cancelled. I want to test if the first job is really cancelled.