Any other hints? I would love to see some sort of specification framework become standard for Kotlin, with support for some sort of doubles/spys/mocking/stubs

I think really it’s an open discussion.

And maybe this channel can serve as that.

There are a few who want the direction of using

Sometihng like this

as function names.

taking advantage of Kotlin being able to escape characters with strings.

The structure it has now is limiting functionality, but at the same time leveraging JUnit

Why would Kotlin escape strings play a role in testing?

I experimented a bit to customize a JUnit

Runner

and a specification base class in form of

@RunWith(AbstractJunitRunner::class)
abstract class AbstractSpec(init: SpecStructure.() -> Unit) {

My goal was to implement something that allows defining hierarchical tests to allow DSLs for TDD and BDD. I haven't much to show, but this is the basic idea behind it.

@iamsteveholmes:

I would love to see some sort of specification framework become standard for Kotlin, with support for some sort of doubles/spys/mocking/stubs

There could be three components: a structure for tests, an assertion library and a mocking/stubbing... library.

I think that's a good idea. Does spek currently meet the first component needs? There is nothing wrong with having competition.

Also kotlin has assertions in the standard lib so I assume you mean something a bit more sophisticated?

But we really have no way to manage doubles

Spek already has special JUnit runner, which provides descriptors compatible with JUnit itself and IDEA

Yeah, in the Java world there are assertions in form of

assertEquals(expected, actual)

(JUnit) and

assertThat(actual, matcher)

. I think Kotlin has something like the former in the standard lib. There are also Groovy's power assertions which are also used in the Spock specification framework.

This is how it basically works and shows given/on/it hierarchical view in IDEA

One of the problems with spek is that based on DSL and lambdas, there is no (easy) way to run specific clause, we simply can’t know what are “on”s, before we execute “given”s, and that could cause side effects and what not

Another problem is that we have to call all the “given" and “on” lambdas and collect them all before we run them, causing lots of memory hanging on closures. Per class, but still.

Next, since “given” introduces closure used in “on”, all “on”s and their “it”s reused the same given-state, which causes specs to be dependent on each other and/or order of execution.

As far as I understand it, spek framework like this should be working alot like LESS simple smile I.e. it should generate flat methods with predefined naming structure that has given/on/it (each path) inlined into their bodies. This way we can enumerate them, run any of them, avoid closures, etc.

Ok. I first thought is was a good idea to have all lambdas in a test structure graph/tree. Maybe I need to implement a basic tree structure to better reason about everything.

You can fork spek — it has all these, may be not ideal, but it has.

Be careful with descriptor IDs, JUnit and IDEA are very sensitive to correct equality, uniqueness, etc. See https://github.com/JetBrains/spek/blob/master/spek-core/src/main/kotlin/org/jetbrains/spek/junit/JUnitClassRunner.kt

Yepp, I saw them. I also looked into

org.jetbrains.spek.junit

to learn about JUnit `Runner`s.

btw, need to update it all to beta…

Be careful with descriptor IDs

you mean

JUnitUniqueId

?

I mean createSuiteDescription and alike, and JUnitUniqueId is dirty hack to avoid thinking too much about correct uniqueness simple smile

JUnit’s extensibility model is not very rich, tbh...

@iamsteveholmes: Ahh, I see. I thought a bit of providing something similiar to chai.js in different assertion styles (should, expect and assert).

My idea is to provide an experimental prototype of a Mocha.js-like testing library. Maybe this could serve as an inspiration for a better Spek implementation. Right now I try to find a lowest common denominator between hierarchical test definitions and JUnit. A data structure that contains lambdas to run and notifiers with descriptoins.