{"id":397,"date":"2025-03-04T17:55:01","date_gmt":"2025-03-04T17:55:01","guid":{"rendered":"https:\/\/imcodinggenius.com\/?p=397"},"modified":"2025-03-04T17:55:01","modified_gmt":"2025-03-04T17:55:01","slug":"getting-started-with-mockk-in-kotlin-1-5","status":"publish","type":"post","link":"https:\/\/imcodinggenius.com\/?p=397","title":{"rendered":"Getting Started with MockK in Kotlin [1\/5]"},"content":{"rendered":"

Before we head there, we will take a quick look at what exactly mocking is, and the differences between several terms that often lead to confusion. Thanks to that, we will have a solid foundation before diving into the MockK and Kotlin <\/strong>topics.<\/p>\n

Getting Started with MockK in Kotlin [1\/5]<\/p>\n

Verification in MockK [2\/5]<\/a><\/p>\n

MockK: Objects, Top-Level, and Extension Functions [3\/5]<\/a><\/p>\n

MockK: Spies, Relaxed Mocks, and Partial Mocking [4\/5]<\/a><\/p>\n

MockK with Coroutines [5\/5]<\/a><\/p>\n

If you enjoy this content, then check out my Ktor Server PRO<\/a> course- the most comprehensive Ktor guide in the market. You\u2019re gonna love it! <\/p>\n

Why Do We Need Mocking?<\/h2>\n

Long story short, we need mocking to isolate the unit \/ the system under test.<\/p>\n

Sounds confusing? No worries.<\/p>\n

Let\u2019s take a look at the typical example of a function:<\/p>\n

So, our function A- the one we would like to focus on in our test- calls both B and C. It can happen sequentially or simultaneously; it doesn\u2019t matter.<\/p>\n

What matters is that when we want to test A, we want to see its behavior in different cases. How does it behave when B returns (for instance) user data successfully? What happens in case of a null value? Does it handle exceptions gracefully?<\/p>\n

And to avoid spending countless hours on manual setup, we use the mocking <\/strong>technique to simulate different scenarios. Mostly with the help of libraries, like MockK.<\/p>\n

The important thing to remember is that mocking is not limited to functions. A, B, and C may as well represent services.<\/p>\n

And in various sources, A will be referred to as the System Under Test (SUT), whereas B, and C will be Depended On Component (DOC).<\/p>\n

Mocking, Stubbing, Test Doubles<\/h2>\n

Frankly, please skip this section if this is your first time with mocking or MockK. I truly believe you will benefit more from focusing on learning MockK-related concepts than slight differences in wording.<\/p>\n

Anyway, from the chronicler\u2019s duty, let me illustrate a few concepts:<\/p>\n

stub <\/strong>is a fake object that returns hard-coded answers. Typically, we use it to return some value, but we don\u2019t care about additional info, like how many times it was invoked, etc.<\/p>\n

mock<\/strong> is pretty similar, but this time, we can verify interactions, too. For example, to see if this was invoked with a particular ID value, exactly N times.<\/p>\n

stubbing<\/strong> means setting up a stub<\/em> or a mock<\/em> so that a particular method returns some value or throws an exception<\/p>\n

mocking<\/strong> means creating\/using a mock<\/em><\/p>\n

and lastly, we use the test doubles <\/strong>term for any kind of replacement we use in place of a real object in your tests (that terms comes stund doubles in movies).<\/p>\n

And if you are looking for a really deep dive, I invite you to Martin Flower\u2019s article<\/a>.<\/p>\n

MockK Imports<\/h2>\n

With all of that said, let\u2019s head to the practice part. <\/p>\n

Firstly, let\u2019s define the necessary imports for MockK.<\/p>\n

We will be working with a plain Kotlin \/ Gradle project with JUnit 5, so our build.gradle.kts dependencies should look as follows:<\/p>\n

dependencies {
\n testImplementation(«io.mockk:mockk:1.13.17»)
\n testImplementation(kotlin(«test»))
\n}<\/p>\n

tasks.test {
\n useJUnitPlatform()
\n}<\/p>\n

The io.mockk:mockk is the only thing we need when working with MockK (unless we want to work with couroutines- but I will get back to that in the fifth lesson).<\/p>\n

Tested Code<\/h2>\n

Then, let\u2019s take a look at the code we are supposed to test:<\/p>\n

data class User(val id: UUID, val email: String, val passwordHash: String)<\/p>\n

class UserRepository {
\n fun saveUser(email: String, passwordHash: String): UUID =
\n UUID.fromString(«aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa»)<\/p>\n

fun findUserByEmail(email: String): User? =
\n User(
\n id = UUID.fromString(«bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb»),
\n email = «found@codersee.com»,
\n passwordHash = «foundPwd»
\n )
\n}<\/p>\n

class EmailService {
\n fun sendEmail(to: String, subject: String, body: String) {
\n println(«Sending body $body to $to with subject $subject»)
\n }
\n}<\/p>\n

class UserService(
\n private val userRepository: UserRepository,
\n private val emailService: EmailService,
\n) {<\/p>\n

fun createUser(email: String, password: String): UUID {
\n userRepository.findUserByEmail(email)
\n ?.let { throw IllegalArgumentException(«User with email $email already exists») }<\/p>\n

return userRepository.saveUser(email, password)
\n .also { userId ->
\n emailService.sendEmail(
\n to = email,
\n subject = «Welcome to Codersee!»,
\n body = «Welcome user: $userId.»
\n )
\n }
\n }
\n}<\/p>\n

As we can see, we have a simple example of a UserService with one function- createUser . The service and the function that we will focus on in our tests.<\/p>\n

And although UserRepository and EmailService look pretty weird, the createUser is more or less something we can find in our real-life code. We check if the given email is taken, and if that\u2019s the case, we throw an exception. Otherwise, we save the user and send a notification e-mail.<\/p>\n

Positive & Negative Scenario<\/h2>\n

Following, let\u2019s do something different compared to other content about MockK. Let\u2019s start by taking a look at the final result, and then we will see how we can get there.<\/p>\n

So, firstly, let\u2019s add the negative scenario:<\/p>\n

class AwesomeMockkTest {<\/p>\n

private val userRepository: UserRepository = mockk()
\n private val emailService = mockk<EmailService>()<\/p>\n

private val service = UserService(userRepository, emailService)<\/p>\n

@Test
\n fun `should throw IllegalArgumentException when user with given e-mail already exists`() {
\n val email = «contact@codersee.com»
\n val password = «pwd»<\/p>\n

val foundUser = User(UUID.randomUUID(), email, password)
\n every { userRepository.findUserByEmail(email) } returns foundUser<\/p>\n

assertThrows<IllegalArgumentException> {
\n service.createUser(email, password)
\n }<\/p>\n

verifyAll { userRepository.findUserByEmail(email) }
\n }
\n}<\/p>\n

As we can see, we start all by defining dependencies for UserService as MockK mocks, and then we simply inject them through the constructor.<\/p>\n

After that, we add our JUnit 5 test that asserts if the createUser function has thrown an exception, nothing unusual. The \u201cunusual\u201d part here is the every<\/em> and verifyAll<\/em> \u2013 those two blocks come from MockK, and we will get back to them in a moment.<\/p>\n

With that done, let\u2019s add one more test:<\/p>\n

@Test
\nfun `should return UUID when user with given e-mail successfully created`() {
\n val email = «contact@codersee.com»
\n val password = «pwd»
\n val createdUserUUID = UUID.randomUUID()<\/p>\n

every { userRepository.findUserByEmail(email) } returns null
\n every { userRepository.saveUser(email, password) } returns createdUserUUID
\n every {
\n emailService.sendEmail(
\n to = email,
\n subject = «Welcome to Codersee!»,
\n body = «Welcome user: $createdUserUUID.»
\n )
\n } just runs<\/p>\n

val result = service.createUser(email, password)<\/p>\n

assertEquals(createdUserUUID, result)<\/p>\n

verifyAll {
\n userRepository.findUserByEmail(email)
\n userRepository.saveUser(email, password)
\n emailService.sendEmail(
\n to = email,
\n subject = «Welcome to Codersee!»,
\n body = «Welcome user: $createdUserUUID.»
\n )
\n }
\n}<\/p>\n

This time, we test the positive scenario, in which the user was not found by the e-mail and was created successfully.<\/p>\n

Defining MockK Mocks<\/h2>\n

With all of that done, let\u2019s start breaking down things here.<\/p>\n

Let\u2019s take a look at what we did first:<\/p>\n

private val userRepository: UserRepository = mockk()
\nprivate val emailService = mockk<EmailService>()<\/p>\n

private val service = UserService(userRepository, emailService)<\/p>\n

So, one of the approaches to define objects as mocks<\/strong> with MockK is by using the mockk function. It is a generic function, so above, we can see both ways in which we can invoke it. It is just an example, and in real life I suggest you stick to either mockk() or mockk<EmailService>() for a cleaner code.<\/p>\n

Alternatively, we can achieve exactly the same with MockK annotations:<\/p>\n

@ExtendWith(MockKExtension::class)
\nclass AwesomeMockkTest {<\/p>\n

@MockK
\n lateinit var userRepository: UserRepository<\/p>\n

@MockK
\n lateinit var emailService: EmailService<\/p>\n

@InjectMockKs
\n lateinit var service: UserService<\/p>\n

}<\/p>\n

The preferred approach is totally up to you. The important thing to mention is that the @ExtendWith(MockKExtension::class) comes from JUnit 5<\/strong>.<\/p>\n

And for the JUnit 4<\/strong>, we would implement a rule:<\/p>\n

class AwesomeMockkTest {
\n @get:Rule
\n val mockkRule = MockKRule(this)<\/p>\n

@MockK
\n lateinit var userRepository: UserRepository<\/p>\n

@MockK
\n lateinit var emailService: EmailService<\/p>\n

@InjectMockKs
\n lateinit var service: UserService<\/p>\n

}<\/p>\n

Missing Stubbing<\/h2>\n

At this point, we know that we don\u2019t use real objects, but mocks.<\/p>\n

Let\u2019s try to run our test without defining any behavior:<\/p>\n

@Test
\nfun `should throw IllegalArgumentException when user with given e-mail already exists`() {
\n val email = «contact@codersee.com»
\n val password = «pwd»<\/p>\n

assertThrows<IllegalArgumentException> {
\n service.createUser(email, password)
\n }<\/p>\n

verifyAll { userRepository.findUserByEmail(email) }
\n}<\/p>\n

Well, we would get something like:<\/p>\n

Unexpected exception type thrown, expected: <java.lang.IllegalArgumentException> but was: <io.mockk.MockKException><\/p>\n

Expected :class java.lang.IllegalArgumentException<\/p>\n

Actual :class io.mockk.MockKException<\/p>\n

Well, the issue is that when we do not specify a stubbing for a function that was invoked, MockK throws an exception<\/strong>.<\/p>\n

But our test logic looks already for exception, so that\u2019s why we got a message that this is simply an unexpected one.<\/p>\n

Without the assertThrows , the message would be more obvious:<\/p>\n

no answer found for UserRepository(#1).findUserByEmail(contact@codersee.com) among the configured answers: (UserRepository(#1).saveUser(eq(contact@codersee.com), eq(pwd))))<\/p>\n

io.mockk.MockKException: no answer found for UserRepository(#1).findUserByEmail(contact@codersee.com) among the configured answers: (UserRepository(#1).saveUser(eq(contact@codersee.com), eq(pwd))))<\/p>\n

So, lesson one<\/strong>: whenever we see a similar message, it means that our mock function was invoked, but we haven\u2019t defined any stubbing.<\/p>\n

Stubbing in MockK<\/h2>\n

And we already saw how we can define a stubbing, but let\u2019s take a look once again:<\/p>\n

val foundUser = User(UUID.randomUUID(), email, password)
\nevery { userRepository.findUserByEmail(email) } returns foundUser<\/p>\n

We can read the above function as \u201creturn foundUser every time the findUserByEmail function is invoked with this, specific email value\u201d.<\/p>\n

When we run the test now, everything is working fine. Because in our logic, if the findUserByEmail returns a not null value, an exception is thrown. So, no more functions are invoked. In other words, no more interactions with our mock<\/strong> object Also, our email value matches.<\/p>\n

And most of the time, this is how I would suggest defining stubbing. This way, we also make sure that the exact value of email is passed.<\/p>\n

When it comes to the answer part, returns foundUser, we can also use alternatives, like:<\/p>\n

answers { code } \u2013 to define a block of code to run (and\/or return a value)<\/p>\n

throws ex \u2013 to throw exception<\/p>\n

and many, many more (I will put a link to the docs at the end of this article)<\/p>\n

MockK Matchers<\/h2>\n

The above stubbing expects that the email value will be equal to what we define.<\/p>\n

Technically, it is the equivalent of using the eq function:<\/p>\n

every { userRepository.findUserByEmail(eq(email)) } returns foundUser<\/p>\n

And eq uses the deepEquals function to compare the values.<\/p>\n

But sometimes, we do not want to, or we cannot define the exact value to match.<\/p>\n

Let\u2019s imagine that some function is invoked 20 times with various values. Technically, we could define all 20 matches.<\/p>\n

But instead, we use one of the many matchers available in MockK, like any :<\/p>\n

every { userRepository.findUserByEmail(any()) } returns foundUser<\/p>\n

And whereas eq is the most concrete one, any is the most generic one. The foundUser is returned if findUserByEmail is invoked with anything.<\/p>\n

And MockK comes with plenty of other matchers, like:<\/p>\n

any(Class) \u2013 to match only if an instance of a given Class is passed<\/p>\n

isNull \/ isNull(inverse=true) \u2013 for null check<\/p>\n

cmpEq(value) , more(value) , less(value) \u2013 for the compareTo comparisons<\/p>\n

and many more that you can find in the documentation<\/p>\n

For example, let\u2019s take a look at the match example:<\/p>\n

every {
\n userRepository.findUserByEmail(
\n match { it.contains(«@») }
\n )
\n} returns foundUser<\/p>\n

As we can see, this way the foundUser will be returned only if the passed value contains @ sign.<\/p>\n

Unit Functions<\/h2>\n

At this point, we know how to deal with matchers and the returns .<\/p>\n

But what if the function does not return anything? We saw that previously, so let\u2019s take a look once again:<\/p>\n

every { emailService.sendEmail(any(), any(), any()) } just runs<\/p>\n

Matchers are irrelevant right now, so I replaced them with any() .<\/p>\n

The important thing here is that just runs is one of the approaches.<\/p>\n

Alternatively, we can achieve the same:<\/p>\n

every { emailService.sendEmail(any(), any(), any()) } returns Unit
\nevery { emailService.sendEmail(any(), any(), any()) } answers { }
\njustRun { emailService.sendEmail(any(), any(), any()) } <\/p>\n

The choice here is totally up to you.<\/p>\n

Summary<\/h2>\n

And that\u2019s all for our first lesson dedicated to MockK and Kotlin. <\/p>\n

As I mentioned above, right here<\/a> you can find the MockK documentation. And although I strongly encourage you to visit it, I also would suggest doing it after my series- when we cover the most important concepts:<\/p>\n

Getting Started with MockK in Kotlin [1\/5]<\/p>\n

Verification in MockK [2\/5]<\/a><\/p>\n

MockK: Objects, Top-Level, and Extension Functions [3\/5]<\/a><\/p>\n

MockK: Spies, Relaxed Mocks, and Partial Mocking [4\/5]<\/a><\/p>\n

MockK with Coroutines [5\/5]<\/a><\/p>\n

The post Getting Started with MockK in Kotlin [1\/5]<\/a> appeared first on Codersee — Kotlin on the backend<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Before we head there, we will take a quick look at what exactly mocking is, and the differences between several terms that often lead to confusion. Thanks to that, we will have a solid foundation before diving into the MockK and Kotlin topics. Getting Started with MockK in Kotlin [1\/5] … <\/p>\n

Read More<\/a><\/div>\n","protected":false},"author":0,"featured_media":398,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-397","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=\/wp\/v2\/posts\/397"}],"collection":[{"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=397"}],"version-history":[{"count":0,"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=\/wp\/v2\/posts\/397\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=\/wp\/v2\/media\/398"}],"wp:attachment":[{"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=397"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=397"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/imcodinggenius.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=397"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}