Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mocking an interface with non-nullable properties sets the properties as null #372

Open
jordigarcl opened this issue Jan 15, 2020 · 3 comments

Comments

@jordigarcl
Copy link

jordigarcl commented Jan 15, 2020

It looks like Mockito is using null as a default value for properties in a interface even though they are non-nullable.

Reproduce:

interface Dog {
  val name: String
}

class DogCaller {
  fun callDog(dog: Dog) = callSomeone(dog.name)
  private fun callSomeone(name: String) = "Hey $name come here!"
}


class DogCallerTests {

  private val dogCaller = DogCaller()

  @Test
  fun `dog caller should call dog by its name`() {
    val beagle: Dog = mock()

    // This makes the test pass 
    // whenever(beagle.name).thenReturn("Firulais")
    
    dogCaller.callDog(beagle)

    verify(beagle).name // This fails cause it detects dog.name : String = null !
  }
}
@bohsen
Copy link

bohsen commented Jan 15, 2020

Your reproducer passes when I try it out. Maybe try checking your imports.

Also returning null is the expected behaviour when a method hasn't been stubbed (depending on the type) - more info here.

@jordigarcl
Copy link
Author

Sorry, now I see I got this error cause inside callDog() I passed dog.name to another function which expected a non-nullable type. That's where the nullability of String check failed.

Though from thecastNull() in the file you referenced I see this is a totally intentional behaviour. Should it be the case though? String has always been a "special" type. I expected the mock to return a '"nice" value such as "".

@bohsen
Copy link

bohsen commented Jan 15, 2020

It would make sense to handle it that way. Would actually solve the issue seen in #241 without using the proposed workaround I believe. Strings have always been kind of problematic in regards to Mockito-kotlin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants