Kotlin-dsl-samples: Feature Request: Add tests to samples/hello-js

[SeanShubin]

I want to be able to test drive my Kotlin code that targets JavaScript

Expected Behavior

If you add the file kotlin-dsl/samples/hello-js/src/main/kotlin/samples/Greeter.kt
```package samples
class Greeter {
fun greet(target:String):String = "Helo, $target!"
}

...and the file kotlin-dsl/samples/hello-js/src/test/kotlin/samples/GreeterTest.kt
```package samples
import kotlin.test.Test
import kotlin.test.assertEquals
class GreeterTest {
    @Test
    fun greetTest() {
        val greeter = Greeter()
        assertEquals("Hello, world!", greeter.greet("world"))
    }
}

...and then run ./gradlew build from the kotlin-dsl/samples/hello-js directory

You should get a failing test because of the typo in the first file.

Upon fixing the typo by changing "Helo" to "Hello", the build should run successfully.

Current Behavior

Currently, you do not get a failing test when the typo exists.

Context

When evaluating new technologies, the first thing I want to know is how to test them.

In my opinion, the primary benefit of tests is that they force you to improve your design until the code is testable. Correctness is an important, but secondary, concern. Incorrect code can be fixed where the problem is, but badly designed code harms all the code around it.

The project https://github.com/jstuyts/kotlin-multiplatform-recipes demonstrates tests using gradle, but I don't currently understand either gradle or kotlin-dsl well enough to convert it. I was also hoping others had played around with different test solutions regarding Kotlin targeting JavaScript.

[StefMa]

Have this issue really something to do with the Kotlin-DSL? 🤔
I mean - this project is not about showing how to test Kotlin (however it is "js" or something different).
The samples are only here to show you how to use the Kotlin-DSL (resp setup a build.gradle.kts file).

[SeanShubin]

I would think of it in terms of adoption by your target audience. It stands to reason that people interested in a gradle kotlin-dsl are also interested in Kotlin. If someone creating a Kotlin project is deciding which build system to use, and they can’t find samples of how to get their tests running with kotlin-dsl but can find samples for vanilla gradle, what should have been a trivial decision to go with kotlin-dsl now becomes a tradeoff.

Any project where adoption is desired, should prioritize the most common and simple use cases to make it easy for adopters to get something working quickly. Super advanced features are interesting, but irrelevant if no one bothers setting up a project in the first place. If it is not obvious how to test something as simple as hello world in javascript Kotlin, it makes it harder to adopt kotlin-dsl.

[tehbilly]

I think tests are extremely beneficial, I often use them to figure out how something works. That's on top of the benefits of having something to catch errors in your examples if future updates break something.

[eskatos]

A pull-request for this would be very welcome

[eskatos]

The hello-js sample uses the outdated kotlin-js plugin that is superseded by Kotlin MPP Javascript support.
Closing as dropped.