Has anybody had ever written timeout tests for Ret...

# coroutines

[alex.tavella]

Has anybody had ever written timeout tests for Retrofit with MockWebServer + coroutines? I’m getting This job has not completed yet on the following test:

@Test
    fun requestWithTimeout_serverRespondsInTime_returnsResponse() = coroutinesRule.testDispatcher.runBlockingTest {
        val body = "{ field: Test }"
        val response = MockResponse()
            .setResponseCode(HttpURLConnection.HTTP_OK)
            .setBody(body)
            .throttleBody(body.length.toLong() / 2, 9, TimeUnit.SECONDS)

        mockWebServer.enqueue(response)

        val actual = service.requestWithTimeout(20_000)

        assertEquals(ResponseTest("Test"), actual)
    }

[jw]

You can look at the built-in tests

[jw]

Your problem is the use of runBlockingTest which I would advise against using in general, but absolutely won't work here.

[ursus]

why

[alex.tavella]

I was using runBlocking and the test passes but it takes too long to complete

[jw]

MWS doesn't honor fake time so you have no choice if this is truly what you want to test.

[jw]

We've talked about having a fake clock as part of Okio in the past

[ursus]

@jw if I might OT, whats wrong with runBlockingTest?

[jw]

Well for one it doesn't work with anything implemented using suspendCoroutine such as Retrofit or anything callback-based.

[ursus]

what then, should I try to make the supsend functions actually blocking in tests?

[jw]

I use normal runBlocking and TestDispatcher for fake time

[ursus]

do you use it as well when fake time is not needed? or swap for Unconfined then? or not care since its runBlocking, and just swap Main if its a view model-thing?

[jw]

Just normal runBlocking otherwise. Turbine means we don't need to swap out dispatchers since it will wait for events and if you're referring to AndroidX ViewModels then we don't use those.

[ursus]

no, just general ui-level business layer, presenter or what have you, which needs android main thread, so dispatchers.main in its scope

[jw]

our UI layer doesn't have coroutines. the view-layer is basically a non-suspending setModel function call. presenters are Rx/Flow streams in, Rx/Flow streams out and they inject the emission scheduler/dispatcher so in the case of Flow it doesn't matter what it used it will still work.

[ursus]

right but the presenter needs to subscribe some upstreams of which data you want to display, transform it, maybe like this

Presenter(someRepository: Repository) {
	val state: Flow<State> get() = _state
	private val _state = MutableStateFlow()
	
	init {
		scope.launch {
			someRepository.whatever
                .someTransforms
				.collect {
					_state.value = it
				}
		}
	}

    fun someClick() {
		scope.launch {
			_state.value = Loading
			someRepository.doSomething()
			_state.value = NotLoading
		}
	}
}

or are they jsut transformations, and not keep state?

[jw]

Ah yeah I see. Right now, for better or worse, they are pure transformations where all state is captured in the stream in some form. I would like to change that and enable something like you describe where local state is used and you can write more imperative code rather than capturing all the logic in Rx/Flow operators.

[ursus]

Yes, and the question is how should the scope instance look like, for now in my code it looks like this

private val scope = CoroutineScope(SupervisorJob() + Dispatchers.main)

or rather the disaptcher instance is injected via ctor

and the question is what should one replace it with during tests. I was used to rx and its Schedulers.trampoline() and keeping everything blocking; but MutableStateFlow doesnt seem to work the same when used with Dispatchers.Unconfined