# Superior Testing: Make Fakes not Mocks

DevFeed: [Superior Testing: Make Fakes not Mocks](<https://devfeed.tech/articles/superior-testing-make-fakes-not-mocks-29377.md>)

Original publisher: [Read original article](<https://arturdryomov.dev/posts/superior-testing-make-fakes-not-mocks/>)

Author: Artur Dryomov

Published: 2019-02-28T00:00:00Z

Content type: tutorial

Language: en

Sources: [Artur Dryomov](<https://devfeed.tech/sources/artur-dryomov.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [Mocking](<https://devfeed.tech/topics/mocking.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [RxJava](<https://devfeed.tech/topics/rxjava.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [mocking](<https://devfeed.tech/tags/mocking.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

The article compares mocking with reusable fakes, or test implementations, in tests for a books repository. It explains that mocking can become bulky and less reusable as code grows, while fakes can reduce repetition and dependency on mocking frameworks. Examples include synchronous and reactive variants, with Kotlin-specific implementation details.

## Source excerpt

After years of writing and reading tests I've discovered that mocking is either overused or underused. Not sure why exactly it happens but striking the right balance seems to be a complicated issue. In this Superior Testing article I'll show how to replace mocking in favor of faking and collect benefits. Mocking Sync Let's say we have a books repository allowing us to get a book based on its ID. The repository depends on the storage. The resulting code is simple enough.