DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,673 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Matt's Tidbits #82 - An unexpected Mockito limitation
Matthew Groves
Matthew Groves

Posted on • Originally published at Medium

Matt's Tidbits #82 - An unexpected Mockito limitation

Last week I wrote about the importance of taking vacation. This time, I have a story to share about an unexpected Mockito limitation.

Consider this example code:

If you want to mock out the ListProvider in your unit tests, it's pretty simple to do the following:

Where this gets tricky is when you think about providing a mock implementation for ListProvider.currentList. At first, I thought about just doing this:

whenever(mockListProvider.currentList).thenReturn(listSubject.value)
Enter fullscreen mode Exit fullscreen mode

The problem with this is that if you post a new value to the listSubject, it will not be reflected in future calls to ListProvider.currentList because the mock (and by extension, the underlying subject) is evaluated at the time it is defined.

One workaround I came up with was to define a method like this for tests:

Using this instead of the listSubject directly allows you to update the mock value for currentList simultaneously.

However, this has some limitationsβ€Š-β€Šnamely, as a coworker pointed out, it's a little bit messy to re-initialize the mock each time.

Thankfully, Mockito provides another option that's a little bit better suited to thisβ€Š-β€Šenter the thenAnswer() method:

whenever(mockListProvider.currentList).thenAnswer { listSubject.value }
Enter fullscreen mode Exit fullscreen mode

Something to be careful of with this method is that it's not type safeβ€Š-β€Šit would be perfectly valid to writeΒ .thenAnswer { 42 }, and you would only find out when running your tests that you had done something wrong.

One more thing to considerβ€Š-β€ŠMockito isn't the most Kotlin-friendly framework out there, so if the majority of your code is in Kotlin, I would highly encourage you to consider MockK, which lets you write this same code like this:

Do you have any ideas/suggestions for how to further improve on this? Let me know in the comments below! And, please follow me on Medium if you're interested in being notified of future tidbits.

This tidbit was discovered on June 25, 2020.

Top comments (0)

DEV has this feature:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›