What's the general consensus on the book using Kot...

# fp-in-kotlin

[pajatopmr]

What's the general consensus on the book using KotlinTest (correct me if I'm wrong, but I now believe KotlinTest has morphed into Kotest)?

[pajatopmr]

Being a long time library developer, I take the stance that if I don't really, really need a third party library then I don't go there. So that makes me wonder what is compelling about Kotest that would make it a good choice?

[pajatopmr]

With Kotlin projects I generally use JetBrains' test stuff (kotlin.test.*) first and then JUnit5 but I have used TestNg and liked it at one company I did a lot of work for back in the early 2000s.

[julian]

@pajatopmr
Generally, I've found kotlin-first libraries to be superior ergonomically to java libraries. So I prefer a Kotlin testing framework.

I've used both Spek and Kotest, which I think are the most widely used Kotlin testing frameworks. I really liked using Kotest and found the maintainers to be very responsive.

One of the major reasons I settled on Kotest was to allow for property-based testing, which is the standard for testing in FP. I don't think kotlin.test provides that.

Kotest also provides a lot of testing "sugar" that's not available in a more bare-bones framework like kotlin.test.

[julian]

Have you checked out #kotest? It's pretty lively.

[pajatopmr]

Good to know, on both accounts. I will check them out. Thanks,

[pajatopmr]

I should probably re-read the material on property based testing (and will!) but can someone summarize for me why property based testing is the standard in FP?

[julian]

@pajatopmr This probably doesn't adequately answer your question, but it's taken from ch 8 of FP in Kotlin, which incidentally also includes a brief exploration of property-based testing using Kotest

This chapter will take us toward a simple but powerful library for automated property-based testing. The general idea of such a library is to decouple the specification of program behavior from the creation of test cases. The programmer focuses on specifying the behavior of a program and giving high-level constraints on the test cases. The framework then automatically generates test cases that satisfy these constraints and runs tests to validate that the program behaves as specified.

[julian]

Here's another explanation

Property-based testing and functional programming are friends, because they’re both motivated by Reasoning About Code. Functional programming is about keeping your functions data-in, data-out so that you can reason about them. Property-based testing is about expressing the conclusions of that reasoning as properties, then showing that they’re (probably) true by testing them with hundreds of different input values.

[julian]

Could you write property-based tests for non-FP code? I don't see why not. But because non-FP code will not consist of pure, total functions, you'll have to do more than that. Because you'll need to verify expected side-effects in addition to verifying function results. Also non-FP code will likely not express data in terms of well-defined types that contain as few instances as possible. This makes expressing meaningful properties more challenging than with FP.

[julian]

This is on my to-read list.

[pajatopmr]

This last link is pretty good. Especially the last part where the author reveals JUnit supports Property-based testing as Theories-based testing.
So, to summarize so far, I like that PBT generates test data; I like that Kotest is pure Kotlin; I like that the JUnit folks have given the concept a vote of confidence; lastly, I'm concerned that my 600 odd tests currently running at 3/4 second will explode and take multiple minutes should I switch to PBT.
Can anyone with PBT experience speak to this performance concern?

[marc0der]

Hi all! Apologies for not visiting here for a while. I was just catching up on this thread (about my favourite topic, testing), and thought I'd also add my 2p about PBT.

First off, I'm a big fan of the outside-in style of testing using acceptance, integration, component and unit tests to express my intent at various levels in the code. Each one is vital at driving out specific behaviour of the code that I'm test-driving. For me this certainly hasn't changed at all when I do FP. So what is PBT good for?

I see this as yet another tool in my toolbox. PBT is great for exercising and validating the laws of functions. This becomes particularly important when you want to test boundary cases in some pure functions. This type of testing has very specific applications, but I certainly don't think it's a silver bullet for every testing situation. For instance, PBT isn't good at expressing intent, and for me that is largely why I write tests! But combined with all the other types of testing, it helps me validate certain pieces of logic that would have taken many unit tests to do.

[marc0der]

About why I chose Kotest above all the others: I feel that Kotest has a lot more to offer in terms of expressiveness. It has a huge thriving community and has matured far beyond all competitors in this space. It provides many different spec styles, has fantastic matchers, and of course a mature PBT implementation. I still think I made the right choice in siding with Kotest for the book 🙂