https://kotlinlang.org logo
#kotest-contributors
Title
# kotest-contributors
s

sam

03/05/2022, 2:35 PM
It's just that none of the testing world supports this - the intellij interfaces for example.
l

LeoColman

03/05/2022, 4:08 PM
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
s

sam

03/05/2022, 4:09 PM
How would you think the syntax would look, test("name").config(pending=true) ?
l

LeoColman

03/07/2022, 7:32 PM
Hmm.. That's a tough one
I know that Kotlin StdLib has the TODO("ABCDE") function
Maybe stealing this syntax might seem a little bit intuitive?
Copy code
class MyTest : FunSpec({
    test("Sum") {
        2 + 2 shouldBe 4
    }

    todo("Subtraction") {

    }

    todo("Multiplication") {

    }
})
And even
Copy code
todo("Division").config( ... = ?) {

}
What do you think @sam @Emil Kantis @Jim
j

Jim

03/07/2022, 7:42 PM
Checks out to me except Todo in kotlin throws an exception and you want skipped right?
e

Emil Kantis

03/07/2022, 7:42 PM
Did you find any good use-cases for the state? All I can think of is cases where I want it to fail anyhow
j

Jim

03/07/2022, 7:43 PM
Yeah it feels like you want to check in to source control incomplete work
l

LeoColman

03/07/2022, 7:45 PM
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
j

Jim

03/07/2022, 7:47 PM
Hmmm then that's:
Copy code
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)
e

Emil Kantis

03/07/2022, 7:51 PM
to me, the failing tests are the
pending
state 🙂 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
l

LeoColman

03/07/2022, 8:04 PM
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
j

Jim

03/07/2022, 8:06 PM
Yeah I use my example to do exactly what you're talking about, I use it to communicate instructions to other devs
5 Views