mockk: Bug: CapturingSlot is not working for nullable types

Prerequisites

Please answer the following questions for yourself before submitting an issue.

  • I am running the latest version
  • I checked the documentation and found no answer (found captureNullable function)
  • I checked to make sure that this issue has not already been filed

Current Behavior

Hello I am not sure whether following behavior is by design or not, but why
class CapturingSlot<T : Any>() require not null type? I have found, that I can capture nullable types with fun captureNullable(list) but can’t with CapturingSlot. So when I change captured type I have to use captureNullable(list) instead of capture(slot)? I did not found definite answer in doc/google.

Example

@ExtendWith(MockKExtension::class)
class SomeTest {
    val strSlot = slot<String>()
    
    @Test
    fun `no answer found for null`() {
        val anotherServiceMocked = mockk<AnotherService>() {
            every { callMe(capture(strSlot)) } just Runs
        }
        
        Tested(anotherServiceMocked).testedFnc(null)
    }

    @Test
    fun `answer found for not null`() {
        val anotherServiceMocked = mockk<AnotherService>() {
            every { callMe(capture(strSlot)) } just Runs
        }

        Tested(anotherServiceMocked).testedFnc("")
    }
}

class Tested(
    private val anotherService: AnotherService
) {
    fun testedFnc(str: String?) = anotherService.callMe(str)
}

class AnotherService {
    fun callMe(str: String?) = Unit
}

Expected behavior

class CapturingSlot<T : Any?>() so val stringSlot = slot<String?>() is possible to create and use to capture values. And capture will behave same for for null and not null values

SW

MockK version: 1.9.3 OS: Win 10 Kotlin version: 1.3.31 JDK version: 11.0.3 jUnit version: 5.1.1

V

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 2
  • Comments: 18

Commits related to this issue

Most upvoted comments

I still would very much like to be able to write something like:

val arg1 = slot<String?>()

slot is easier to use than mutableList

+1

Available in 1.13.7

I see your point, @andriygg.

Currently you can work around it by using a mutableList rather than a slot, so I wouldn’t consider adding support for nullable types in slots as a high priority feature request.

Anyways, a PR for it would definitely be cool 😃

Closing this as it looks like using the mutableList version of capturing slots solves it.