A modern programming language that makes developers happier.

kotlinlang

It's just that none of the testing world supports this - the intellij interfaces for example.

If we start supporting it just in meta-data from our test output writer I think it's a good start

And in IntelliJ + JUnit we can treat it as a failure

How would you think the syntax would look, test("name").config(pending=true) ?

I know that Kotlin StdLib has the TODO("ABCDE") function

Maybe stealing this syntax might seem a little bit intuitive?


```class MyTest : FunSpec({
    test("Sum") {
        2 + 2 shouldBe 4
    }

    todo("Subtraction") {

    }

    todo("Multiplication") {

    }
})```

And even

```todo("Division").config( ... = ?) {

}```

What do you think <@U12AGS8JG> <@UVAR0DXP0> <@U016VMY2A72>

Checks out to me except Todo in kotlin throws an exception and you want skipped right?

Did you find any good use-cases for the state? All I can think of is cases where I want it to fail anyhow

Yeah it feels like you want to check in to source control incomplete work

Yes! That's part of the reason.
Leaving it explicit that there is still work to do in that test

Maybe that can be split to the rest of the team

I don't have a use-case for the `pending` state yet, just for the pending syntax. It would help remembering to write all the tests that I thought

Or if I don't have energy to write complex ones, I leave scenarios prepared for contributors to implement

I think I thought of it more as a syntax sugar than a feature on itself. At least to start

Hmmm then that's:

```test("mult").config(enabledOrReasonIf = Enabled.disabled("issue #1337") { sut(2).times(2) shouldBe 4 }```

Then in ij it shows as skipped and logs that issue (or whatever string)

to me, the failing tests are the `pending` state :slightly_smiling_face: as master/main branch should never have any failing tests.. Adding failing tests to indicate scenarios that should be handled, and just `test("Multiplication") { TODO("implement me") }` is good enough imo? It’s easy to replace the inner TODO, and it uses built-in language features so most people would recognize it. Works with all spec-styles as well..

that said.. I suppose everything depends on what kind of workflow you’re accustomed to.. and if you’re working in a code-base where failing/flaky tests are normal - then perhaps distinguishing to-be-implemented scenarios from just one of the usual flaky/failing tests could add value

My main use case, and from where the idea comes from, is thinking of a test scenario while writing another one

And wanting to write it down ASAP so that I don't forget to implement it later on

test("XXX") { TODO("ABC") }

Works fine as a workaround indeed

I wanted to discuss if we think having a more specific syntax for this can enable other kinds of work-flow without confusing new users

And idk where this would lead to. Don't know how costly it would be to maintain, to document, to keep it up-to-date..... It's all pretty abstract in my mind now

Yeah I use my example to do exactly what you're talking about, I use it to communicate instructions to other devs