Ahh ... it looks like when tests are excuted via gradle + cli my custom AbstractProjectConfig isn't ...

# kotest

[tim]

Ahh ... it looks like when tests are excuted via gradle + cli my custom AbstractProjectConfig isn't being executed ... is that normal behaviour? I had to look at the stack trace to see that my tests were never running due to missing env variables which im currently setting in my PorjectConfig.

[sam]

Should work regardless if its on the classpath

[tim]

I must be missing something 🤔 It works as expected when I run: gradle :project:test --tests "com.example.MyTest" but the following fail (because there are no env vars set) gradle :project:test --tests "com.example.*" or gradle :project:test or gradle :project:check ??

[sam]

Is the config in the same module as the test

[tim]

yes

[sam]

Is the first one definitely running the test and not skipping it

[tim]

[sam]

Put an init block in your project config and in that init block throw an exception. Then run gradle check and see if it errors out

[tim]

[tim]

two sec

[tim]

gradle :cloud:test --tests "io.glimpseprotocol.cloud.SingleVaultTest" fails when the init block throws

[sam]

Ok I think your error is that you need the use junit block in every gradle file or gradle gets confused

[sam]

The useJunitPlatform thing

[tim]

ahh

[tim]

2 sec

[tim]

doesn't appear to have had any effect

[sam]

I'm pretty sure that's the cause

[sam]

A test block in every module including root with useJunitPlatform

[tim]

[tim]

🤷‍♂️

[sam]

Humour me and make the tests block top level in each file

[tim]

👍

[tim]

No joy 😞

[tim]

In case it helps here are the two files in question

[sam]

I had this exact error on kotest itself for a while and couldn't figure it out. Then I found that it was because gradle would find no tests (because no test engine was configured) and would report that as an error.

[sam]

Ahh I have this in kotest as well

[sam]

filter {
isFailOnNoMatchingTests = false
}

[sam]

https://github.com/kotest/kotest/blob/fbc7934e99a6fcaed22c9a050c8223444c6d2607/kotest-extensions/build.gradle.kts#L52

[tim]

Still failing, but slightly different error message after adding the filter block (top is without the filter block)

[tim]

Here's the stack trace if thats helpful

[tim]

[sam]

GLIMPSE_SERVICE_NAME must not be null

[tim]

That value is set inside TestConfig's AbstractProjectConfig block ...

[tim]

... which brings us back to my initial comment in the main channel 😂

[sam]

lol

[sam]

well now we've fixed the gradle check thing

[sam]

can you show me your config class

[tim]

package io.glimpseprotocol.cloud

import io.kotest.core.config.AbstractProjectConfig
import io.kotest.core.listeners.Listener
import io.kotest.extensions.system.SystemEnvironmentProjectListener

class ProjectConfig : AbstractProjectConfig() {
//    init {
//        error("I'm an error!!!!")
//    }

    override fun listeners(): List<Listener> = listOf(
        SystemEnvironmentProjectListener(
            mapOf(
                "GLIMPSE_ENV" to "test",
                "GLIMPSE_SERVICE_NAME" to "cloud",
                "GLIMPSE_VERSION" to "x.x.x-test",
                "GLIMPSE_PORT" to "20001",
                "GLIMPSE_DOMAIN" to "localhost",
                "GLIMPSE_ROOT_PATH" to "/cloud/v1",
                "GLIMPSE_COOKIE_ENCRYPT" to "covfefeecovfefee",
                "GLIMPSE_COOKIE_SIGN" to "covfefeecovfefee",
                "GLIMPSE_MONGO_URI" to "<mongodb://127.0.0.1:27017/?readPreference=primary&ssl=false>",
                "GLIMPSE_LOGGING_LEVEL" to "debug"
            )
        )
    )
}

[sam]

I think what's happening is the env var is trying to be used before the listeners are firing to set the env vars. Do you have that System.envVar(GLIMPSE_SERVICE_NAME) in a static initializer block

[tim]

i do yes

[sam]

Ok, so gradle will find your test classes first, which causes those init blocks to fire, then passes the classes over to the test engine, in this case kotest

[sam]

note: static init block is not the same as an init block in a class

[tim]

I assuem you mean something like this:

[sam]

anything in an object will be executed as soon as the class is loaded by the classloader

[sam]

so way before kotest can get involved

[tim]

makes sense

[tim]

hmm how to get around 🤔

[sam]

so you could maybe make it lazy

[tim]

ya

[tim]

could I use lazy?

[sam]

you would need to make the private val lazy

[sam]

and the object env might need tweaking as well, not sure

[tim]

okay i'll have to play around with this and see if I can get it to work a bit later running out of time before the weekend 🙂 I assume I could just set the env variables inside gradle? Not ideal but could be a workround in the interim.

Thank you for your help though 🙏

[sam]

Yes you could do that

[sam]

and probably is better anyway as env vars ideally should be set before the program starts - setting them in kotest is a bit of a hack as it has to use reflection to change the map

[tim]

I can't recall the reason I put them there, but I just started using kotest like a week ago so 🤷‍♂️

[sam]

There's nothing super bad about it, but I think it's better if it's in the gradle file or whatever.

[sam]

The kotest env listeners are really intended where you want to tweak an env var while running in order to test that something changes with different values.

[tim]

I prefer them in gradle as well ... they were there a few days ago but I can't recall why I moved them into the test config 🤔

[tim]

Hey @sam sorry for being a pain. I've tried moving environment variables into build.gradle.kts but now the kotest extension doesn't pickup the variables (iirc this is why I originally used SystemEnvironmentProjectListener).

Should kotest be picking up env varialbes from build.gradle.kts? If not, how do people reconcile thier cli test running from the idea test running?

[sam]

kotest picks up env from the shell like any program. My guess is gradle isn't passing them through (forked process?)

[sam]

https://stackoverflow.com/questions/23689054/problems-passing-system-properties-and-parameters-when-running-java-class-via-gr <-- this seems relevant

[tim]

hmm thats annoying!

[tim]

i'll take a look at SO and see how striaghtforward it is to expore them into the forked process

[tim]

thanks!

[sam]

looks like its fairly easy

[sam]

or you could include them in whatever script you use to start it

[tim]

ahh ya seems striaghtforward