Skip to main content

Command Palette

Search for a command to run...

Kotlin Code Smell 21 - Mocking Business

Mockumentary: When Your Test Takes Acting Too Far

Updated
2 min read
Kotlin Code Smell 21 - Mocking Business
Y

I've started to work as a software engineer at 2014, however, I started to write code at high-school.

My first language was Assembly, but still, I fall in love with the possibilities to make the computer to do as you wish, shortly after that I started to write in C.

Later on I studied a practical engineering in electricity, and during this time discovered that I preferred much more writing code than design electrical components.

As a result of this understanding I decided to switch and study bachelor degree in computer science in Reichman university, where the focus was of the Java language.

Today I'm working at SumUp using Kotlin, SpringBoot & Micronaut, Cassandra and Kafka

Problem

  • Complexity

  • False sense of security.

  • Parallel/Paired objects (real and mocks) can lead to maintainability issues.

  • Maintainability

Solution

  • Mock just non-business entities.

  • Remove the mock if its interface has too much behavior.

Sample Code

Wrong

class PaymentTest {
    @Test
    fun `process payment should return true on successful payment`() {
        val paymentDetails = mapOf(
            "amount" to "100",
            "currency" to "USD",
            "cardNumber" to "1234567890123456",
            "expiryDate" to "12/20",
            "cvv" to "123"
        )

        // We should not mock a business object
        val payment = mockk<Payment>()
        every { payment.process(any(), any()) } returns true

        // This is an external and coupled system.
        // We have no control on it so tests might be fragile
        val authorizeNet = AuthorizeNetAIM(Payment.API_ID, Payment.TRANSACTION_KEY)

        val result = payment.process(authorizeNet, paymentDetails)
        assertTrue(result)
    }
}

Right

class PaymentTest {
    @Test
    fun `process payment should return true on successful payment`() {
        val paymentDetails = mapOf(
            "amount" to "100",
            "currency" to "USD",
            "cardNumber" to "1234567890123456",
            "expiryDate" to "12/20",
            "cvv" to "123"
        )

        val payment = Payment()

        // External system is mocked
        val response = Response(approved = true, transactionId = "1234567890")
        val authorizeNet = mockk<AuthorizeNetAIM>()
        every { authorizeNet.authorizeAndCapture() } returns response

        val result = payment.process(authorizeNet, paymentDetails)
        assertTrue(result)
    }
}

Exceptions

  • Mocking accidental problems (serialization, databases, APIs) is a very good habit to avoid coupling.

Conclusion

Mocks, like other test doubles, are valuable tools. Using them judiciously is an art.

Imagine a play in which each actor, instead of rehearsing with other actors, had to interact with 25 scriptwriters. The actors would never rehearse together. How would the result of the play be?

Credits

Kotlin Code Smells

Part 16 of 36

In this series, we will see several symptoms and situations that make us doubt the quality of our development. We will present possible solutions. Most are just clues. They are no hard rules.

Up next

Kotlin Code Smell 20 - Settings/Configs

Settings Spaghetti: When Configurations Go Wild...

More from this blog

Yonatan Karp-Rudin | kotlin for backend developer skills | java for backend developer skills | SpringBoot | Tutorials

57 posts

Experienced Senior Software Engineer passionate about functional programming & Kotlin. Excels in app development, optimization, and team collaboration. Let's create something amazing!