Unit testing support for helper classes

Hi, I have seen https://github.com/holgerbrandl/kscript/issues/207 but that seems focused on testing scripts themselves. Testing the kts file is not something I’m interested in because:

• scripts can be long and complicated
• they can involve disk and network dependencies that are hard to involve in tests
• They can require user input
• Their outputs may not be simple, such as generating files

Instead, I am interested in traditional junit tests for helper functions and classes that the script uses.

I would be open to seeing how to do this outside of kscript - but I feel like kscript might need internal changes to make this work well because:

• the generated project with --idea would ideally support showing and running the tests
• Packaging the script (--package) would ideally skip any dependencies that are for test only (such as junit)

While I’m not sure exactly what this would look like, here is one idea I can propose.

Imagine a setup with three files

• MyScript.kts
• MyHelper.kt
• MyHelperTest.kt

Where MyScript uses MyHelper class, and MyHelperTest has tests for the MyHelper class.

The MyHelperTest.kt can declare test dependencies with an annotation indicating it is for testing only.

@file:TestDependsOn("junit:junit:4.12")

MyScript.kts can declare files that contain tests

@file:TestInclude("./MyHelperTest.kt")

Then the nice behavior that kscript could provide is

• Intellij project created with --idea would put the test files in a test sources folder and add testImplementation dependencies. Tests would run with junit out of the box
• running the script or packaging it with kscript would skip the test files and dependencies (to speed up compilation and reduce dependency size)
• A new command like kscript --test could enable easy testing of all of a script’s tests

I could potentially help with this implementation if there is support and alignment! Thank you for the consideration.

[holgerbrandl]

Sure that would be great. If you could potentially also add some bits to the user_guide illustrating the discussed approach for script testing it would be perfect.

[elihart]

@egor-n thanks for sharing your approach. That seems reasonable if you don’t mind the overhead of creating a permanent gradle project to house your scripts, which I would like to avoid (although maybe it could be a good fallback option)