Will arrow 2.0.0 have updated documentation around...

# arrow

[Kev]

Will arrow 2.0.0 have updated documentation around testing using mockk and the raise dsl?

[dave08]

I know there's some controversy in this subject... but I found that tests that mainly use Mockk have been a real PAIN to manage... I usually create fakes and stubs that do the job much better and Intellij can help in generating/refactoring them... there are still cases where Mockk can come in handy when you don't have control over certain classes.

[dave08]

When using Fakes/stubs testing with Arrow isn't complicated either...

[Alejandro Serrano.Mena]

I'm not 100% sure what you mean with MockK and Raise, but if you have some ideas of better docs, feel free to open an issue against the arrow-website repo

[Larry Garfield]

How are you making fakes? (Says someone still very new to Kotlin whose team is not well versed in testing…)

[CLOVIS]

Test doubles (the common term for mocks, fakes, and a few other techniques) are used to replace dependencies of the system-under-test, by something you can control to observe the behavior of the system-under-test.

Mocks often use "magic" to control the behavior of dependencies: byte-code manipulation, etc. They allow you to force a system to behave differently than it is coded to. Mocks are easy to setup in codebases that are not structured in any particular way, so they are popular, but the magic has a few downsides (hard to debug, hard to run tests in parallel, hard to understand, not KMP).

But, if you think about it, what you're trying to do is just substituting some behavior by another one. That's just regular code, that's an interface ! Instead of writing a system that directly accesses its dependencies, you write it to accept an interface that describes its dependency. In production code, you can give it the real implementation. In test code, you can create a new implementation that does whatever your test finds convenient. It's as simple as implementing the interface, there's no magic at all. That's a fake.

[Larry Garfield]

OK, so you’re just making a one-off of the interface in question. What do you do if you have no interface to work from, because it’s someone else’s API? (Context: I’m very familiar with testing techniques and fakes vs mocks, and have written at length about why you should always use fakes instead of mocks… in PHP. 🙂 I’m still learning what the equivalent tools are in Kotlin to achieve the same result, since the preferred PHP tool, anonymous classes, isn’t available.)

[CLOVIS]

We do have anonymous classes: https://kotlinlang.org/docs/object-declarations.html

[CLOVIS]

Do you have a more specific question? This is a bit vague to write anything about

[Kev]

@Alejandro Serrano.Mena when dealing with mockk and mocking a methods that use the raise dsl, i have to wrap most of the mockking code in an either block which feels very dirty. Then if you wrap that in one either block and execute whatever function you’re testing (in another either block because its using the raise dsl) it complains that the expected first parameters (being the raise dsl context) blows up. This feels hacky.

[Larry Garfield]

Eh, probably off topic for this room. Better over in #getting-started. 🙂 But good to know anon classes are a thing! (No one else on my team seemed to be aware of that. Which… Sigh.)

[dave08]

@Larry Garfield We have something like this for faking lambdas (with a bunch of overloads) -- most of our use cases are `fun interface`s so it gets useful when use cases depend on others or you pass lambdas a lot...:

class SLambdaFake3<A, B, R>(var result: R) : suspend (A, B) -> R {
    val calledWith = mutableListOf<Pair<A, B>>()

    override suspend fun invoke(a: A, b: B): R {
        calledWith.add(Pair(a, b))

        return result
    }

    fun reset() {
        calledWith.clear()
    }
}

the result var can be used to control the result returned and the calledWith can replace the verify { } in Mockk... a lot of fakes can be built with such patterns to make testing easier and clearer and then you don't loose your IDE type safety and refactoring features.

[Larry Garfield]

Oh my. Much there to study, as I’ve never used suspend…

[Riccardo Cardin]

Simon asked me to write a post on this issue…my bad, it’s still in my queue…