Just another day wishing that Quarkus worked with ...

# kotest

[Gavin Ray]

Just another day wishing that Quarkus worked with Kotest pepecry

(I actually don't understand why it doesn't, since Quarkus apparently uses JUnit lifecycle/extension methods and Kotest is compatible with them)

[Emil Kantis]

Feel free to chip in 🙂 https://github.com/kotest/kotest/issues/1401

[Emil Kantis]

Personally never worked with Quarkus, so would be hard to help..

[Gavin Ray]

I actively contribute to Quarkus, but the JUnit extension is written/maintained primarily by one person and it's quite a bit of code.

Started a discussion about it on Quarkus' side (just over a year ago today!) but nothing ever came of it unfortunately =/
https://github.com/quarkusio/quarkus/issues/19749

[sam]

The quarkus junit stuff seems to do a lot of magic classpathy stuff. What they really need to do is make it test framework agnostic.

[Gavin Ray]

Maybe I'll burn another weekend on it this week, I love Kotest but in particular the Testcontainer extension API is too nice to miss out on

[sam]

Happy to spend time on this too, but I looked at the existing junit quarkus stuff and it's not for someone who doesn't know or use quarkus imo. Maybe if they started just pulling it out into not a huge class it would help understanding of it.

[sam]

Spring keeps it well abstracted, and so it's easy (ish) to plug into Spring. Eg they have their own before/after test interfaces, so junit and kotest can both map to that.

[Gavin Ray]

Aye, something like:

public class JunitTestRunner implements QuarkusTestRunner {}

Instead of just

public class JunitTestRunner

[sam]

yes

[Gavin Ray]

Will have to try to figure out how you can debug the test runner, I wasn't sure how to do this

Not sure if putting breakpoints in the runner source and launching gradle would work, doesn't seem like it would be so easy

[Emil Kantis]

You would probably need to attach the debugger to the right pid, but it should be doable