Hey lovely people - just a question - what are cap...

# multiplatform

[Matthias Geisler]

Hey lovely people - just a question - what are capabilities of a mocking lib in KMP you would expect/like to have?

[iamsteveholmes]

I was searching for mocking libs in my project and I tried a few. I can’t recall the name of it but they had a dependency on a google library. I set them up as shown but they all failed for me. So for me I’d just like a mocking library to work on android, ios and JS.

[Matthias Geisler]

Nothing special like relaxing, spying?

[iamsteveholmes]

Mocks, Fakes, Spys are great. Relaxing is also fantastic.

[Nicklas Jensen]

@iamsteveholmes, was it Mockative by any chance? I am the author, and if you had trouble setting it up and would like some assistance feel free to reach out to me 🙂

[kpgalligan]

I’m curious if you’re going to start working on this. At present, all mocking libraries that work for native only support interfaces. A mocking library to actually mock classes would need to be a compiler plugin. We talk about trying it periodically, but obviously a big undertaking.

[Matthias Geisler]

Actually I am close to finish with my own Mocking Lib after having issues with MocKMP. However @Nicklas Jensen did a great job to be honest...but I wanted the setup phase smaller like MagicMock in Python and I missed some features. I sticked to the Interface only approach this far with KSP (like all the others), since I believe it leads to a more reasonable architecture in the end (but I other people have different opinions on that I believe). From what I know about compiler Plugins - they are "not much harder" to work with than KSP, right? (since they operate on the AST. But I am possibly wrong here)

[kpgalligan]

I’m not sure compiler plugins aren’t much harder. Part of the issue is the learning curve. There’s not as much documentation as there is just source to dig through. KSP is intended to be more of a “public” api, so it’s probably more straightforward to learn. I have minimal experience with either, though.

[kpgalligan]

On “more reasonable architecture”, I tend to agree. We wrote an interface-only “mock” library a couple years ago (used intellij to generate code rather than something at compile time: https://github.com/touchlab/Karmok). In general, we just implemented our own interfaces for testing anyway, so that library got abandoned. I think we’re going to pick one of the current ones as our “official” internal recommendation, but haven’t done the eval yet. Part of why we haven’t dug into a compiler plugin mocking library, besides the obviously large amount of work to do so, is if we’d internally get a whole of use with it anyway. From a platform perspective, though, it would be good if KMP had something. It would also be good if it was clear to new devs that there is no full mocking available. I feel like I see “I tried this but it doesn’t work on native” regularly.

[kpgalligan]

To some degree it is expectations. Most KMM devs are coming from JVM/Android, and (I think) view the lack of a full mocking library as a sign of platform immaturity. However, there’s not equivalent for Swift, as like Kotlin/Native it is a very static language, but unlike K/N, there’s no “compiler plugin” equivalent. Our intellij plugin library was started as a copy/paste of an AppCode plugin to generate mocks for Swift.

[Matthias Geisler]

Actually I used Karmok about a year ago...back when my Company still invested in KMP...I was actually sad that touchlab discontinued this, since I think a mocking lib is quite essential for further success of Kotlin.

[kpgalligan]

(Here’s the origin: https://github.com/seanhenry/MockGenerator)

[Matthias Geisler]

It's also crucial from JS side I suppose...even if writing mocks by hand is not that hard...in the end the time you spend on that still sums up in the end.

[kpgalligan]

Yeah, the Karmok thinking was that as soon as KSP was stable there would be multiple implementations of interface-only mocking libraries, and you need to invest the time/effort to maintain each library. As the platform matures, it will be difficult for one group to have valuable open source across many projects. It’s a long way of saying libraries consolidate and it’s better to do a couple things really well than try to do a lot of things 🙂

[kpgalligan]

So, sorry we dropped it 🙂

[Matthias Geisler]

Shall I bump a link to thing I am actually doing, when I cleaned it up? (I am still smoothing a bit the API...and some other stuff) But do not expect to much, it needs more smoothing and its only my personal preference in the end and its just my sample project, since I want to leave my current company.

[Matthias Geisler]

Totally understand that point with maintainability...but KSP makes it (more or less) easy.

[kpgalligan]

Please do! Also, I assume nobody from your current company hangs out in the slack channel 👀

[Matthias Geisler]

Only my ex boss, I guess...but he is possibly looking for something new for himself (they shutdown the Android Team...so no KMP anymore only Swift)

[Matthias Geisler]

He for example wrote a awesome FHIR Lib for KMP

[kpgalligan]

Well, I only found one FHIR library for KMP, so that kind of narrows it down 🙂 Sorry the shut down the team. Please send the link when you do clean up (no rush, though. I’m sort of off for a while anyway. Just lurking in slack)

[Matthias Geisler]

I hope you found this one. And sure...I hope to wrap it up today (for my own sake 😄)

[Matthias Geisler]

@kpgalligan I think I have a first showable version (took a bit longer than expected since I run in some trouble with the memory model)...Its laking the capability of arbitrary shared sources (I don't have the time right now, but I actually know how to get there), but it will run with commonTest. You find an example project here. The actual code base can be found here. Both together should carry the idea behind, even if I had not the time for an appropriate documentation.

[Matthias Geisler]

Ola - I am not sure if anybody is still listing on this thread...however I advanced a bit in the topic of this thread and updated my little mock library accordingly. kmock supports now arbitrary shared sources like nativeTest like regular platform sources and I finally managed to write a more or less proper documentation. So any feedback would be much appreciated!
Aside from this advertisment block I also took a deeper look into compiler plugins. I think currently to work with them instead of KSP is very bad gamble since many things are moving around in my impression in the compiler. This means the cost of maintenance is simply too hight. But there is at least a possibility to make classes usable. The idea is to make classes which are used for mocks simply open so the actual mock can use old fashioned inheritance. I already managed to do that locally with the big hammer, so that needs further refinement. Before you ask how - Kotlin has already a compiler plugin with similar capabilities - all-open, so you get an impression on that.
However in my ideal world, like with other modern frameworks, Kotlin itself should come with mocking capabilities, iff they are compiler based, to keep them reliable. For now it would be a big step if Kotlin would ship with a compiler plugin similar to the already mentioned one above, which opens simply either all classes during tests or provides an API which is usable while running tests, so anybody can take advantage of that and the approach would be reliable.
Long message, I am sorry for that...