DEV Community: Kotest

Kotest Release 4.3

Stephen Samuel — Sun, 11 Oct 2020 19:44:47 +0000

The Kotest team is pleased to announce the release of Kotest 4.3.0.

This blog covers some of the new features added in this release.
For the full list, see the changelog.

New and improved data driven testing

Kotest has improved its data driven testing support, directly integrating into the framework. This means it will now automatically generate individual test case entries.

As an example, lets test a function that returns true if the input values are valid pythagorean triples.

fun isPythagTriple(a: Int, b: Int, c: Int): Boolean = a * a + b * b == c * c

We start by writing a data class that will hold each row - a set of inputs.

data class PythagTriple(val a: Int, val b: Int, val c: Int)

Next we invoke the function forAll inside a test case, passing in one or more of these data classes, and a
lambda that performs some test logic for a given row.

context("Pythag triples tests") {
    forAll(
       PythagTriple(3, 4, 5),
       PythagTriple(6, 8, 10),
       PythagTriple(8, 15, 17),
       PythagTriple(7, 24, 25)
    ) { (a, b, c) ->
        isPythagTriple(a, b, c) shouldBe true
    }
}

Kotest will automatically generate a test case for each input row, as if you had manually written a seperate test case for each.

For full documentation click here.

EnabledIf annotation on specs

It can be useful to avoid instantiating a spec entirely, and often we can do that via test tags. But if you want to do this with some bespoke code, then the annotation EnabledIf has been added.

Annotate a spec with EnabledIf, passing in a class that extends from EnabledCondition and that condition will be invoked at runtime to determine if the spec should be instantiated. The EnabledCondition implementation must have a zero arg constructor.

For example, lets make a condition that only executes a test if it is midnight.

class EnabledIfMidnight : EnabledCondition {
   override fun enabled(specKlass: KClass<out Spec>): Boolean = LocalTime.now().hour == 0
}

And then attach that to a spec:

@EnabledIf(EnabledIfMidnight::class)
class EnabledIfTest : FunSpec() {
   init {
      test("tis midnight when the witches roam free") {
        // test here
      }
   }
}

TestCase severity

Test case can be conditionally executed via test tags, and now also by severity levels. The levels are BLOCKER, CRITICAL, NORMAL, MINOR, and TRIVIAL.

We can mark each test case with a severity level:

class MyTest : FunSpec() {
   init {
      test("very very important").config(severity = TestCaseSeverityLevel.CRITICAL) {
        // test here
      }
   }
}

Say we only want to execute tests that are CRITICAL or higher, we can execute with the system property kotest.framework.test.severity=CRITICAL

This can be useful if we have a huge test suite and want to run some tests first in a seperate test run.

By default, all tests are executed.

Disabling source references

Whenever a test case is created, Kotest creates a stack trace so that it can link back to the test case. The stack trace contains the filename and line number which the Intellij Plugin uses to create links in the test window. It calls these the sourceref.

If you have 1000s of tests and are encountering some slowdown when executing the full suite via gradle, you can now disable
the generation of these sourcerefs by setting the system property kotest.framework.sourceref.disable=true

Generally speaking, this is only of use if you have a huge test suite and mostly aimed at CI builds.

Make engine dependency free

A test framework is one of the lowest levels of dependences in an ecosystem. As Kotest is used by many Kotlin libraries, a clash can occur if Kotest and your project are using the same dependencies but with different versions.

It is beneficial then if Kotest has as few dependencies as possible. To this aim, 4.3.0 has seen the dependencies for the Kotest framework reduced to just Classgraph (to scan for specs), Mordant (for console output), and opentest4j.

Matchers return 'this' for easy chaining

In the opinion of this author, Kotest has the most comprehensive assertion support for Kotlin. Now they just became more convienient, by allowing you to chain assertions together if you wish.

So, instead of

val employees: List<Employee> = ...
employees.shouldBeSorted()
employees.shouldHaveSize(4)
employees.shouldContain(Employee("Sam", "Chicago"))

You can now do

val employees: List<Employee> = ...
employees.shouldBeSorted()
         .shouldHaveSize(4)
         .shouldContain(Employee("Sam", "Chicago"))

Of course, this is entirely optional.

Property test module for kotlinx datetime

Kotest's expansive property test library now includes generators for the incubating kotlinx datetime library.

Add the module kotest-property-datetime to your build. These generators are available for JVM and JS.

For example:

forAll(Arb.datetime(1987..1994)) { date ->
   isValidStarTrekTngSeason(date) shouldBe true
}

Option to strip whitespace from test names

If you like to define test names over multiple lines, Kotest will now strip out leading, trailing and repeated whitespace from test names.

For example, the following spec:

class MySpec : StringSpec() {
  init {
   """this is a
      test spanning multiple lines""" { }
  }
}

Would normally be output as

this is a      test spanning multiple lines

By setting the configuration object removeTestNameWhitespace to true, this would instead by output as

this is a test spanning multiple lines

Thanks

Huge thanks to all who contributed to this release:

AJ Alt, Alex Facciorusso, Ashish Kumar Joy, J Phani Mahesh, Jasper de Vries, Javier Segovia Córdoba,
Josh Graham, KeremAslan, Leonardo Colman, Michał Sikora, Mitchell Yuwono, Neenad Ingole, Rick Busarow,
SergKhram, Sergei Khramkov, crazyk2, sksamuel

Testing Kotlin/JS with Kotest

Stephen Samuel — Sun, 20 Sep 2020 19:17:03 +0000

One of the areas Kotlin has focused on in recent releases is with multi-platform support. Kotlin code, the Kotlin standard library and other supported dependencies can be compiled into ES5 Javascript.

When targeting platforms that are not JVM based, our options for testing are reduced. The two best known Java testing frameworks (JUnit and TestNG) are JVM specific and won't work when we compile to Javascript. Instead, in this short article I will show how it is possible to use Kotest to test against Kotlin/JS.

Firstly, I will assume you already have a project setup with javascript support. If not, then follow this guide.

This means you will end up a structure that contains a main source folder and a test sources folder as is usual, with the koltin-js standard library added.

Let's add a basic Javascript function that validates US social security numbers. This will be the function that we want to test with Kotest.

Inside the source root, we create a file called ssn.kt that contains the following code:

import kotlin.js.RegExp

private val socialRegex = RegExp("^\\d{3}-\\d{2}-\\d{4}$")

fun validateSocial(ssn: String): Boolean {
   return socialRegex.test(ssn) && !ssn.contains("0") && !ssn.startsWith("666")
}

You'll notice we are using the kotlin.js.RegExp class. This is a Kotlin wrapper around the built in Javascript regular expression support. This is one of the nice touches about Kotlin's multi-platform support - it allows you to use platform specific functions, rather than going down lowest common denominator path of only allowing functions that work on all platforms.

There are some basic rules when it comes to validating SSN numbers. The general format is a 3 digit area code, a 2 digit group code, and a 4 digit serial number. Our function requires hyphens between these sets of numbers.

Additionally, no number can be zero, and 666 is not valid as an area code.

Setting up the build for Kotest

To begin testing, we need to add the appropriate Kotest dependencies. These are kotest-framework-engine-js and kotest-framework-api-js for the test framework, and kotest-assertions-core-js for the assertions library. Note that the assertions library is optional, in case you want to use assertions from another library.

If you are not using coroutines already, you will need to bring in the kotlinx-coroutines-core-js dependency in as well.

So, your build file should contain something similar to this:

kotlin {

   js {
      browser()
   }

   sourceSets {
      test {
         dependencies {
            implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core-js:1.3.9'
            implementation 'io.kotest:kotest-assertions-core-js:4.2.5'
            implementation 'io.kotest:kotest-framework-api-js:4.2.5'
            implementation 'io.kotest:kotest-framework-engine-js:4.2.5'
         }
      }
   }
}

Writing a Test

To begin writing our tests, we create a Spec. A spec is the name Kotest uses for a class that contains test definitions. These are just regular classes that extend one of the Kotest spec styles. For Javascript we must choose one of the simpler specs - FunSpec in this case.

import io.kotest.core.spec.style.FunSpec
import io.kotest.matchers.shouldBe

class SsnTest : FunSpec({

   test("a SSN should be invalid when it contains a zero in any position") {
      validateSocial("543-23-5013") shouldBe false
      validateSocial("043-23-5313") shouldBe false
      validateSocial("313-03-5310") shouldBe false
   }
})

Nested inside the constructor lambda block is our first test case. We check that if a zero appears inside the SSN then it is not valid.

Executing this test is just a matter of invoking the gradle test task, either at the command line, or from within intelliJ. The Kotlin/JS plugin for gradle will take care of downloading Mocha and/or Karma depending on whether the project is Browser and/or NodeJS based.

And, if all goes well, you should see something like this:

Let's round out our test suite, by adding tests to confirm the 666 rule, and that inputs must be in the required 3-2-4 format.

import io.kotest.core.spec.style.FunSpec
import io.kotest.matchers.shouldBe

class SsnTest : FunSpec({

   test("a SSN should be invalid when it contains a zero in any position") {
      validateSocial("543-23-5013") shouldBe false
      validateSocial("043-23-5313") shouldBe false
      validateSocial("313-03-5310") shouldBe false
   }

   test("a SSN should be invalid when it starts with 666") {
      validateSocial("666-23-1234") shouldBe false
   }

   test("a SSN should be in the required format") {
      validateSocial("123-45-6789") shouldBe true
      validateSocial("123-45-678") shouldBe false
      validateSocial("12-45-6789") shouldBe false
      validateSocial("1234-56-678") shouldBe false
      validateSocial("123456789") shouldBe false
      validateSocial("123-456789") shouldBe false
      validateSocial("12345-6789") shouldBe false
      validateSocial("") shouldBe false
   }

})

Coroutines and Promises

The interop of Kotest and Javascript doesn't stop there. Every test in Kotest is executed inside of a coroutine, so we can test suspend functions directly. Internally these are mapped to Javascript Promises.

We're going to test a function that uses the Ktor HTTP client to connect to a public API to fetch a picture of a dog.

Firstly, add implementation 'io.ktor:ktor-client-js:1.4.0' to your main source. Then create a new file called http.kt which contains the following function:

import io.ktor.client.HttpClient
import io.ktor.client.engine.js.Js
import io.ktor.client.request.get
import io.ktor.client.statement.HttpResponse
import io.ktor.client.statement.readText

private val client = HttpClient(Js)

suspend fun fetch(): Dog {
   val resp = client.get<HttpResponse>("https://dog.ceo/api/breeds/image/random")
   return JSON.parse<Dog>(resp.readText())
}

data class Dog(val message: String, val status: String)

This fetch function invokes the API, returning an instance of Dog, parsed from the returned Json. Notice the use of the JSON.parse function which is part of the Kotlin/JS std library. There is no error handling here since this is just a simple example of suspendable functions in action.

The next part is of course to write the test:

import io.kotest.core.spec.style.FunSpec
import io.kotest.matchers.string.shouldEndWith

class DogTest : FunSpec({
   test("fetching a dog using JS promises") {
      fetch().message.shouldEndWith(".jpg")
   }
})

As you can see, testing a suspend function is as easy as testing the validateSocial function from earlier.

And just to prove that the test is indeed waiting for the response to complete, we can add an incorrect assertion to see the test fail.

import io.kotest.core.spec.style.FunSpec
import io.kotest.matchers.string.shouldEndWith

class DogTest : FunSpec({
   test("fetching a dog using JS promises") {
      fetch().message.shouldEndWith(".jpg2")
   }
})

That's how simple it is to use Kotest for Javascript tests. Kotlin/Javascript interop is still somewhat new and so there are some restrictions that you may run across.

The full project can be found here.

Writing reusable tests with Kotest's Test Factory

Leonardo Colman Lopes — Thu, 16 Apr 2020 20:02:59 +0000

TL;DR - How to use Kotest 4.0.0 new Test Factory feature to include reusable blocks of test in your test suite

Hello, Kotliners!

In this article we'll see how to use a feature from the Kotest Framework to create reusable tests in your test suite, for cases in which you test multiple classes exactly the same way.

Declaring a Test Factory function

It's very easy to create a reusable test. You must first pick your favourite style among Kotest's test styles. You can pick any of them, but my personal favourite (and the one I'll use here) is FunSpec.

Declaring a test using FunSpec is as simple as:

class MySpec : FunSpec({
    test("Foo should not be equal to bar") {
        "foo" shouldNotBe "bar"
    }
})

Declaring the same test, but this time as a test factory is very similar:

// Top level val
val myReusableTest = funSpec {
    test("Foo should not be equal to bar") {
        "foo" shouldNotBe "bar"
    }
}

However, there are some cases in which having the same test will produce a different result if called multiple times. For cases which our tests depend on some parameters, we might rather want to use use this as a function:

fun myReusableTest(myParameter: String) = funSpec {
    test("$myParameter should not be equal to bar") {
        myParameter shouldNotBe "bar"
    }
}

Both cases can be included in any Spec by using the include function:

class MyTest : FunSpec({
    test("My usual test") {
        // ...
    }

    include(myReusableTest("A"))
    include(myReusableTest("B"))

    test("Another usual test") {
        // ...
    }
})

And as expected, the tests from the test factory are applied!

A small example

Now that we understand the basic concept, let's play a little bit with a more realistic example: Calculators! ~~really realistic, everyone implements calculators~~

Let's suppose we have 3 types of calculators:

A Sum Calculator
A Subtraction Calculator
A Complete Calculator, that can do both operations.

interface SumOp {
    fun sum(a: Int, b: Int): Int
}

object SumCalculator : SumOp {
    override fun sum(a: Int, b: Int) = a + b
}

interface SubtractionOp {
    fun subtract(a: Int, b: Int): Int
}

object SubtractionCalculator : SubtractionOp {
    override fun subtract(a: Int, b: Int) = a - b
}

To test these implementations, we would create a Spec for each:

class SumCalculatorTest : FunSpec({
    test("Sum 2 and 2 should be 4") {
        SumCalculator.sum(2, 2) shouldBe 4
    }
})

class SubtractionCalculatorTest : FunSpec({
    test("4 minus 2 should be 2") {
        SubtractionCalculatorTest.subtract(4, 2) shouldBe 2
    }
})

When implementing our CompleteCalculator, we should test these behaviours as well.

object CompleteCalculator : SumOp, SubtractionOp {

    override fun sum(a: Int, b: Int) = a + b

    override fun subtract(a: Int, b: Int) = a - b
}

class CompleteCalculatorTest : FunSpec({
    test("Sum 2 and 2 should be 4") {
        CompleteCalculator.sum(2, 2) shouldBe 4
    }

    test("4 minus 2 should be 2") {
        CompleteCalculator.subtract(4, 2) shouldBe 2
    }
})

We have ended up writing the same test that we already wrote for sum calc and sub calc. This is duplication that we'd like to try and avoid.

Now let's exercise what we learned previously. Writing tests through composition:

fun sumTests(calc: SumOp) = funSpec {
    test("Sum 2 and 2 should be 4") {
        calc.sum(2, 2) shouldBe 4
    }
}

fun subtractionTests(calc: SubtractionOp) = funSpec {
    test("4 minus 2 should be 2") {
        calc.subtract(4, 2) shouldBe 2
    }
}

class SumCalculatorTest : FunSpec({
    include(sumTests(SumCalculator))
})

class SubtractionCalculatorTest : FunSpec({
    include(subtractionTests(SubtractionCalculator))
})

class CompleteCalculatorTest : FunSpec({
    include(sumTests(CompleteCalculator))
    include(subtractionTests(CompleteCalculator))
})

And voilà! We successfully reused a test for more than one scenario!

What could this be useful for?

In the real world we won't be implementing calculators as often as we want to. So, why would I use this kind of factory and composition?

We created these Test Factories for any kind of repeatable test pattern. For example:

If you need to test that every Repository<MyEntity> creates a database entity with a new ID
If your cache and your actual database return data in the same format
If sending a POST request to some endpoint always returns the payload in a specific format
If all instances of a sealed class have their class' name on the toString function

And much more scenarios that you might be exploring with!

Testing Koin applications with Kotest

Leonardo Colman Lopes — Mon, 22 Jul 2019 15:09:16 +0000

TL;DR - Using the KoinListener from Kotest to write tests that depend on Koin modules in a Kotest Spec

Hello, Kotliners!

In this article we will see how to test applications that use the Koin DI Framework in a Spec from the Kotest Framework. We'll take the JUnit example from Koin's documentation and enhance it with Kotest.

3 simple steps

Add Kotest's Koin extensions to your build.gradle
Transform your JUnit test into a Kotest Spec (or create one from scratch)
Add the KoinListener to your class

Add Koin extension to your build.gradle

On your build.gradle file we'll add the Koin Extension dependency as a testImplementation. I'm assuming you already have Kotest configured. If you don't, take a look at the docs on how to do it.

I like to keep the Koin Extension definition close to my Kotest definition

build.gradle

dependencies {
    // ... Your dependencies ... 

    // Kotest
    testImplementation("io.kotest:kotest-runner-junit5:{version}")
    testImplementation("io.kotest:kotest-extensions-koin:{version}")

}

Transform a JUnit test to a Kotest Spec

For this example, we are going to use the JUnit example from the Koin docs:

class MyTest : KoinTest {

    // Lazy inject property
    val componentA : ComponentA by inject()

    // use it in your tests :)
    @Test
    fun `make a test with Koin`() {
        startKoin { modules(appModule) }

        // use componentA here!
    }
}

Converting the test

There are a lot of styles that can be used in Kotest, let's try with FunSpec

class MyTest : FunSpec(), KoinTest {


    // Lazy inject property
    val componentA : ComponentA by inject()

    init {
        test("Make a test with Koin") {
            startKoin { modules(appModule) }

            // use componentA here!
        }
    }

}

This will already work!

This example works in the same way as the JUnit code. If we add more tests to the class, we'll have to clear Koin's context. In JUnit we create a @After method. Let's see how to do this in Kotest

Add KoinListener to the class

To fix this, we can either override the afterTest function, that works similarly to @After or we can use the KoinListener to do that automatically for us! Let's try with that approach:

class MyTest : FunSpec(), KoinTest {

    override fun listeners() = listOf(KoinListener(appModule))

    // Lazy inject property
    val componentA : ComponentA by inject()

    init {
        test("Make a test with Koin") {

            // use componentA here!
        }
    }

}

With KoinListener we will have Kotest handle both Koin's start (see that we removed that line in our test!) and Koin's stop.

And that's it!

With this simple setup, you'll be able to test your Koin Application with Kotest, and use all the available features from both of them!

If you still have any doubt, check out the full documentation on KoinListener

Testing System Properties and System Environment with Kotest

Leonardo Colman Lopes — Sun, 21 Jul 2019 21:16:50 +0000

TL;DR: Test code that uses System.getenv() or System.getProperty() with easy-to-use functions with Kotest

Hello Kotliners!

In this article we'll discuss a little bit two features of Kotest:

System Environment extensions
System Property extensions

They're very similar on their implementation and use, and are very easy to use!

The problem

In the JVM world, some (many) times our code depends on what the system provides us, usually through Environment Variables or Properties passed to the JVM.

However, neither is very easy to test when we want to use it.

The System.getenv() map is immutable. We can't set it up using plain Java
Messing with System.setProperty() manually forces us to do all the setup and tear-down, and becomes very verbose and cumbersome


Photo by Victoria Heath on Unsplash

The solution

Kotest provides some extensions and listeners to handle these scenarios. The complete documentation can be found here

System Environment Extensions

If the piece of code under test is small enough and used only once, we can use the withSystemEnvironment. It has overloads, but we'll use the key and value one. There's an overload expecting a Pair<K,V> and one expecting a Map<K,V>

class EnvironmentTest : FunSpec() {
    init {
        test("Changing environment") {
            withSystemEnvironment("fooKey", "barValue") {
                System.getenv("fooKey") shouldBe "barValue"
            }
        }
    }
}

System Properties Extensions

In the same fashion as above, we have the function withSystemProperties, that works very similarly:

class PropertyTest : FunSpec() {
    init {
        test("Changing System Properties") {
            withSystemProperties(mapOf("fooKey" to "barValue", "booKey" to "batValue")) {
                System.getProperty("fooKey") shouldBe "barValue"
                System.getProperty("booKey") shouldBe "batValue"
            }
        }
    }
}

Cleanup

After the execution, the previous values will be set to what they were before. What is already in the map will remain untouched during the execution.

Test Listeners

Perhaps your code require the specific properties in every test. You can configure the SystemPropertyTestListener and the SystemEnvironmentTestListener for that:

class SystemEnvironmentTestListenerTest : FunSpec() {

    override fun listeners() = listOf(
            SystemEnvironmentTestListener("fooKeyEnv", "barValueEnv"),
            SystemPropertyTestListener("fooKeyProp", "barValueProp")
        )

    init {
        test("System Property") {
            System.getProperty("fooKeyProp") shouldBe "barValueProp"
        }
        test("System Environment") {
            System.getenv("fooKeyEnv") shouldBe "barValueEnv"
        }
    }
}

The original values will reset after the test execution.

Project Listener

You can also set these globally by using the SystemEnvironmentProjectListener and the SystemPropertyProjectListener. More information on Project Configuration can be found in Kotest's Docs

class ProjectConfig : AbstractProjectConfig() {
    override fun listeners(): List<TestListener> = listOf(SystemEnvironmentProjectListener("foo", "bar"))
}

Override Mode

All the above extensions accept a parameter of the enum OverrideMode.

SetOrOverride - If the key we want to set is already in the properties/environment, we want to override it for the test
SetOrIgnore - If the key is already present, we'll not override it and the test will continue
SetOrError (default) - If the key is already present, interrupt the test with an Exception

These are very useful if you need to use, for example, a property in the global listener, but want to override it in a specific test.

withSystemProperty("foo", "bar", OverrideMode.SetOrOverride) {
    // foo is overrided here
}

Extensions in action

I've published 2 small and simple libs that exercise these listeners and extensions:

SimpleProperties - That reads values both from Environment and Properties. Test Class. It's even possible to see both extensions used at once
SimpleFeatureThrottler - A similar approach can be seen in this test class

Testing a Spring Boot application with Kotest

Leonardo Colman Lopes — Thu, 11 Jul 2019 03:49:44 +0000

TL;DR - How to use the SpringListener from Kotest to test Spring Boot applications, including some samples

Hello Kotliners!

In this article we'll see how to test Spring Boot apps using the Kotest Framework. We'll see some examples on how we test things using JUnit, and how to easily move to Kotest and enjoy it's features.

3 simple steps

Add Kotest's Spring Extension to your build.gradle
Transform your JUnit test into Kotest format (or create a new test from scratch)
Add the SpringListener to your class

Add Kotest Spring Extension

On your build.gradle file we'll add the Spring Extension dependency as a testImplementation. I'm assuming you already have Kotest configured. If you don't, take a look at the docs on how to do it.

I like to keep the Spring Extension definition close to my Kotest definition

build.gradle

dependencies {
    // ... Your dependencies ... 

    // Kotest
    testImplementation("io.kotest:kotest-runner-junit5:{version}")
    testImplementation("ioio.kotest.extensions:kotest-extensions-spring:{version}")

}

Transform a JUnit test to a Kotest Spec

For this part we'll assume that we already have a component in our application:

@Component
class SimpleComponent {
    fun foo() = "Bar"
}

Yes yes, it's very simple and very dummy... But stay with me, we will go step by step!

We usually write a JUnit + Spring integrated test for this, validating that this bean works correctly.

There.are.many.guides that show us how to do it. Let's take this basic approach:

@RunWith(SpringRunner::class)
@SpringBootTest
class SimpleComponentTest  {

    @Autowired
    private lateinit var simpleComponent: SimpleComponent

    @Test
    fun fooShouldReturnBar(){
        Assert.assertEquals("Bar", simpleComponent.foo())
    }
}

Transform that test in a Kotest Spec

There are a lot of styles that can be used in Kotest, let's try with FunSpec.

Let's convert it exactly as is:

@RunWith(SpringRunner::class)
@SpringBootTest
class SimpleComponentTest : FunSpec() {

    @Autowired
    private lateinit var simpleComponent: SimpleComponent

    init {
        test("foo should return Bar") {
            simpleComponent.foo() shouldBe "Bar"
        }
    }
}

Aaaand our test crashes.

kotlin.UninitializedPropertyAccessException: lateinit property simpleComponent has not been initialized

It's ok, it's ok! We need to tell Kotest that this is a Spring Test!

Add the SpringListener to the class

To fix the above error, we need to add the SpringListener to our class' listeners:

@SpringBootTest
class SimpleComponentTest : FunSpec() {

    override fun listeners(): List<TestListener> {
        return listOf(SpringListener)
    }

    @Autowired
    private lateinit var simpleComponent: SimpleComponent

    init {
        test("foo should return Bar") {
            simpleComponent.foo() shouldBe "Bar"
        }
    }
}

Notice that we also removed the @RunWith(SpringRunner::class), as we are not running with JUnit anymore.

And voilà, it works!

Of course this is a very modest example. What about all the other configurations? Profiles, context configuration, TestConfiguration?

Don't worry! they'll work the same way as we're used to in JUnit. Annotating the constructor and such.

For example, messing with profiles:

@SpringBootTest(classes = [Components::class])
@ActiveProfiles("test-profile")
class ActiveProfileSpringTest : FunSpec() {

    override fun listeners() = listOf(SpringListener)

    @Value("\${test-foo}")
    lateinit var testFoo: String

    init {
        test("Should load active profile properties correctly") {
            testFoo shouldBe "bar"
        }
    }

}

test from Kotest test suite

And this is all we have for today! Go ahead and test your Spring Apps with Kotest! More information on this extension can be found at the docs

Doubts? Suggestions? Leave us a comment!