I remember asking something similar. But how does ...

# javascript

[andylamax]

I remember asking something similar. But how does one run integration tests with kotlin/js? To precise, I need to run my tests after a docker container has started. How?

[Big Chungus]

Start the container via gradle task (worker api should be useful) and inject urls, ports and the like by expanding some props into js test output

[andylamax]

Let me look into worker api then. I was not aware of it

[ephemient]

a shared build service is generally useful for setting up an external resource to be used by other tasks

[ephemient]

I think another task or workers would not be a good fit, since there isn't a way to express "start this thing before these tasks and shut it down after"

[andylamax]

After watching a couple of talks and reading through Worker API. I can safely say, Worker API is not what I am looking for. Let me try checking shared build service

[andylamax]

Hey there, I wen't through gradle build service thoroughly, and while I get its use case, 'useful for several tasks to share resources and state' , I am failing to see how this will help me achieve the goal of writing integration test that would run with kotlin/js.

Let me try to break down the problem and process to provide more clarity.

Problem
I have a multiplatform interface MonitorApi (currently targeting android,jvm,browser and nodejs. With potential of expanding to ios) with two concrete implementations
• class MonitorApiMock : MonitorApi
• class MonitorApiKtor : MonitorApi
At the moment, I have a large set of tests that use the MonitorApiMock implementation. I need to be able to run the same tests with MonitorApiKtor but this now needs a running server instance, because it actually make http calls to the said server.

Approach
Initially, I used test containers and they seem to work flawlessly but only for jvm. So I abandoned ship to the second approach

I have been testing manually by starting the server and giving gradle some environment variable (e.g. API=KTOR ./gradlew allTests)
In the Jvm and NodeJs I can easily read this environment variable and decide which implementation to use at runtime. However this fails me in browser.

Possible Suggestions?
I need a way I can inject this environment variable in a test environment and decide it at runtime as well

or

I am willing to write a testcontainers equivalent (looks like the suitable desired outcome) that works for MPP. I don't how (yet), but I don't see how a gradle build service would be the tool I need for now.

Any solid pointers would be heavily appreciated

[turansky]

https://www.npmjs.com/package/string-replace-loader ?

[turansky]

I even have adapter

[Vampire]

Sharing resources and state among tasks is just one of the use-cases of a build service.
You asked for a way to start a docker container before your test task and shut it down afterwards.
And that's also a use-case covered by build services.
That's what the other guys tried to say.

[Matthias Geisler]

Why you not add a custom Gradle Task which generates a BuildConfig? You will only need a few lines of code...

[andylamax]

@turansky I can see how I can use kfc-plugins to achieve injection of env variables into kotlinjs

[andylamax]

@Vampire I understand now, let me try to do that and see where it takes me

[andylamax]

@Matthias Geisler I think I should try this too. I'd be easier to have build config objects on a multiplatform level. I have never done this for a library though. Only applications

[Matthias Geisler]

Super easy...let me know if you need inspiration

[andylamax]

Feeedback:
Injecting a build config from a custom gradle tasks works likes a charm. Now onto a build service