Kotlin scripting would allow you to embed the Kotlin compiler in your app. There’s several nice examples but sadly there isn’t a hands-on to learn from. Here’s the link to the KEEP if you want an under the hood look at things: KEEP/scripting-support.md at master · Kotlin/KEEP · GitHub
One thing to consider is where you will be writing the DSL and if you can get tooling support. Kotlin DSLs are great because they support tooling with no cost as it’s just part of the language.
When embedding the compiler you can get similar tooling when editing your custom scripts inside Intellij.
The result is a fully tooled custom file similar to build.gradle.kts. Instead of Gradle tooling included by default, your code is included. You can manage imports and handle compiling any way you want (e.i. You might provide an @dependsOn("myfile.custom.kts") annotation to enable script dependencies).
Another question to ask is: Is your DSL close to YML? Or in other words, is this something you can boil down to simple predefined actions so it looks like GitLabCI or GitHub Actions? A Kotlin DSL would definitely provide you with more control as you have full scripting access, type-safety, and autocompletion. However, it may still be better to start on how your use-case is modeled in a pure data format first.
It sounds like you want a portable DSL. If that DSL is simply data that doesn’t need to be scripted or have logic in it, see how it would look in a mark-up language. (This is the opposite of when you find you’re “coding in JSON/YML” as your mark-up starts to get control flow, operators, etc. That’s when you want to look for a more robust scripting solution).
If that’s the route you go, you can always add on a Kotlin DSL. For example, this Kubernetes DSL. This gives tooling and programmatic support to writing tests.
Finally, have you looked at existing DSLs for writing test scenarios? Cucumber is the first that comes to mind. You write “feature” files that describe your tests and implement that binds the tests to implementation in whatever language you want. This way would allow you to write BDD scenarios platform independently and implement the glue in the native language for the project. There’s tooling support for Cucumber in IntelliJ.
TL:DR
There are some really great benefits to Kotlin embedded scripting, but it may not fit your use case.
Is your DSL portable data? Or is it meant to be have programmatic control flow and more complex logic? (this might move things closer to a fully blown language)
Where are you writing the test DSL? IntelliJ, a text simple editor (VSCode, Atom, etc)? Is tooling important? (Or maybe it’s meant to be simple enough to not matter)
Have you looked at existing test solutions for describing test scenarios (Cucumber maybe)? I suspect Cucumber may provide what you’re looking for–independent test scenarios.
