# Mocking Matchers API: Handling Nullable and Non-Nullable Arguments in mockito-kotlin

DevFeed: [Mocking Matchers API: Handling Nullable and Non-Nullable Arguments in mockito-kotlin](<https://devfeed.tech/articles/mocking-matchers-api-38651.md>)

Original publisher: [Read original article](<https://krossovochkin.com/posts/2021_09_11_mocking_matchers_api/>)

Published: 2021-09-11T00:00:00Z

Content type: tutorial

Language: en

Sources: [Vasya Drobushkov](<https://devfeed.tech/sources/vasya-drobushkov.md>)

Topics: [Mocking](<https://devfeed.tech/topics/mocking.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [code](<https://devfeed.tech/tags/code.md>), [exception](<https://devfeed.tech/tags/exception.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [library](<https://devfeed.tech/tags/library.md>), [mocking](<https://devfeed.tech/tags/mocking.md>)

## AI overview

This article examines how mocking libraries design their APIs, using mockito-kotlin to explain why matchers for nullable and non-nullable inputs behave differently. It also discusses duplication in mock setups and when a fake object may be preferable.

## Source excerpt

Introduction Recently, I faced an issue that in the first place I found weird. I even considered that the behavior is generally incorrect. Diving deeper I got few insights on the problem - and this is what I'd like to share with you. This is a story about the interesting behavior of mocking library and the difficulties of defining API surface for a library. Disclaimer In general, I favor fakes over mocks. In other words, instead of trying to implement emulation of the behavior as a mock - it is generally easier and safer to implement a simple fake object with all the logic (that can be covered with tests if needed). Though that doesn't mean that one should not use mocks at all. In my opinion, it depends on the use case. If you would like to stub some values - then going with a fake object sounds like a wise choice, but for verifying behavior (e.g. whether there were interactions with a particular object or not) using mocking libraries might provide a fast solution. Needed to say that even when trying to verify interactions one can use fake objects wrapped with spies. Regardless, this article is not about what approach is better, it is more about the behavior of mocking libraries and how their API is designed.