Wrote a small post about tweaking some Kotest sett...

# kotest

[Emil Kantis]

Wrote a small post about tweaking some Kotest settings related to classpath scanning in order to achieve faster test run times. Hope it's of use to someone 🙂 https://kantis.github.io/posts/Faster-Kotest-startup/

[Sebastian Schuberth]

Thanks, just going through it to review 😉 One thing I've found: There's a typo in kotest.framework.discovery.jar.scan.disabled which should say kotest.framework.discovery.jar.scan.disable without "d".

[Sebastian Schuberth]

And IMO a linkt o the reference at https://kotest.io/docs/framework/framework-config-props.html would be great, although it unfortunately does not document the meaning of kotest.framework.discovery.jar.scan.disable ...

[Sebastian Schuberth]

...I'm looking into contributing docs for kotest.framework.discovery.jar.scan.disable, but I'm actually unsure of its effect. This basically toggles ClassGraph.disableJarScanning() when scanning for Kotest configs, but what's the actual effect when disabling this? Will only third-party JARs (of my project's dependencies) not be scanned for Kotest config, or will also JARs produced by subprojects of my own (root) project not be scanned?

[Emil Kantis]

Does Gradle use JARs for project dependencies? 🤔 If so, then yes.

[Sebastian Schuberth]

I believe it does not, as an optimization, to avoid actually building the JARs unless you distribute.

[Sebastian Schuberth]

I just tried, and my (shared) ProjectConfig is still found despite kotest.framework.discovery.jar.scan.disable = true 👍🏻

[Emil Kantis]

Adjusted the post to fix the typo'd property.. great find, thanks 🙂

[Sebastian Schuberth]

I also realized at some point that when running "Kotest"-type run configurations, those Gradle-base test properties are not taken into account, and I saw the respective warning about classpath scanning on the console. However, I'm not setting those properties in Gradle, but in kotest.properties which resides next to my ProjectConfig, and now I don't see these warnings anymore even with "Kotest"-type run configurations. Is that expected, does it actually work?

[Sebastian Schuberth]

> If your project consists of many modules, it can be tedious to duplicate this configuration in each module, so I personally prefer the Gradle config.
Regarding that, I simply have a test-utils Gradle module with my ProjectConfig and kotest.properties that all my tests depend on.

[Emil Kantis]

kotest.properties should work w/ both types of run configuration, afaik

[Emil Kantis]

That's also an option, yes. I think some might consider it a bit tedious to set up a separate Gradle module for that, but definitely an option if you're comfortable with configuring builds

[Emil Kantis]

Might be worth it's own post at some point 🙂

[Sebastian Schuberth]

Otherwise you could also leverage the idea-ext Gradle plugin to configure presets for run configurations, similar to this.

[Emil Kantis]

ohh sweet! that's a way better way of doing it 🙂

[Lidonis Calhau]

Why not make it default behaviour for Kotest so it's fast by default ?

[Sebastian Schuberth]

It will become the default with Kotest 6.

[Sebastian Schuberth]

It's a breaking change, so it requires a major version bump, according to SemVer.

[Lidonis Calhau]

Ah ok thanks, I will wait for Kotest 6 then 🙂

[Victor Cardona]

After disabling classpath scanning any specs that use the Spring Extension fail with

io.kotest.engine.spec.SpecInstantiationException: Could not create instance of class com.example.Spec. Specs must have a public zero-arg constructor.

Does this change how we are supposed to activate extensions?

[Emil Kantis]

Yes. You need to create a Kotest config and declare the extension there

[Emil Kantis]

I can give an example on how to do this later when I’m at the computer

[Victor Cardona]

So extensions must be activated globally?

[Emil Kantis]

The Spring extensions do. Extensions that you normally activate in a spec can be done the same way still.

[Victor Cardona]

@Emil Kantis when you have a moment can you share an example please? I've added the following project config

object KotestConfig : AbstractProjectConfig() {
    override fun extensions(): List<Extension> = listOf(SpringExtension)
}

but whenever I set either

kotest.framework.discovery.jar.scan.disable=true

or

kotest.framework.classpath.scanning.autoscan.disable=true

all tests using SpringExtension fail to instantiate.

[Emil Kantis]

You need to point Kotest to the config as well. See https://kantis.github.io/posts/Faster-Kotest-startup/#using-a-kotest-config-without-scanning

[Victor Cardona]

I did. I have kotest.framework.config.fqn=com.hellofresh.rms.processors.KotestConfig in my kotest.properties.

[Emil Kantis]

https://kotest.io/docs/extensions/spring.html#constructor-injection

[Emil Kantis]

If you’re using constructor injection for the tests

[Victor Cardona]

Thank you! I had missed that.

[Emil Kantis]

All good now?

[Victor Cardona]

Yes. Thank you!