Haha! But folks who code in JavaScript are accustomed to nasty scope issues. I think it's best to avoid that.

set the channel topic: A specification framework for Kotlin: https://github.com/JetBrains/spek

hmm, seems the execution order is very wrong in spek

besides the problem with

afterOn()

in https://github.com/JetBrains/spek/issues/39

class FooSpec : Spek() { init {
    given("") {
        beforeOn { print("1") }
        on("") {
            print("2")
            it("") {
                print("3a")
            }
            it("") {
                print("3b")
            }
        }
    }
}}

this outputs "123a3b" (and something with

teamcity[...]

), but should output "123a123b" (or "123b123a" 😃).

to store the references of lambda functions is not a big deal. the Kotlin plugin seems to have some problems with nullable function literals, but with a wrapper object it works

Hmm, JUnit's

Runner

needs to know at least the name of the first test within the suite or it will create a test description and name it

<no name>

.

-.txt

I think for convenience we should allow an internal suite context. currently I don't know if

value

should be

1

or

11

within the `test()`s. In case of

1

it would need to - first run the upper part of

suite("define suite)

, - then

suiteSetup()

, - then

test("define foo test")

- and then the lower part of

suite("define suite")

. I personally think the bevavior with

value == 1

is better and

suiteCleanup()

should handle the teardown. But it could be the case, that we need to stick to the

value == 11

behavior, because some lambdas within

suite("define suite")

have to be evaluated first.

@hastebrot: that’s precisely the issue. It’s the wrong sequence.

Any reason to use spek over something like Spock/Robospock. Spek seems to be missing a lot of things.

Spock and Robospock are excellent. I think the idea of spek is to have a native-to-kotlin specification testing library

I think the idea of spek is to have a native-to-kotlin specification testing library

yeah, Spock uses a lot of "magic" syntax. AST transformations for

when:

,

then:

and

mock()

and Spek uses extension functions, which are easier to handle implemenation-wise

I use Spock for approx. five years, and there are cases where the structure of Spock's

Specification

classes is a bit restrictive

but this restrictive, flat syntax (with only

where:

to repeat cases) could also be an advantage

Spock is great. I have only been using it for a short time. I can just write all the tests with strings and explain what they should do before actually writing much code. I really dig that I don't have to write lots of brackets, don't have to think much about the actual test framework and can fully concentrate on the actual test.

If you're looking for something today Spock is probably your best bet. Straight JUnit is another option.

@a.paslavsky we've been using this channel for discussing Kotlin Testing, including mocking/doubling. If you would like to be part of that conversation your input would be appreciated:

there are the interfaces

Specification

,

Given

,

On

,

It

. they are necessary in combination with function extensions (

T.() -> Unit

) to express the hierarchical structure of specifications. their implementations also store

recordedActions

,

beforeActions

,

afterActions

. in the prototype I build I wanted to use a traversable, hierarchical data structure

Node<T>

and find a way to

populate()

it from the specification and

transform()

it so that a call to

traverse()

is only required to "execute" the suites and tests in correct order. which means the "actions" are stored in the tree structuren differently and we can remove subtrees to get rid of allocated memory.

yesterday I made some progress. it looks like we need a tree with weighted edges, at least this was the most plausable structure I found. the new implementation traverses the tree in correct order. it pays attention to `setup()`s of parent `Node`s and places them before `setup()`s of the current

Node

. it is also possible to propagate and transform the tree

Node

after

Node

. this is required because propagating a subtree means we also execute some parts of the specification itself.

That seems like a good way to go. I assume you would then make

Given

,

On

,

It

Nodes or

describe

nodes depending on your taste

yes. you use Kotlin's builder pattern (for Spek's `given()`/ `on()`/

it()

or Mocha's `describe()`/

it()

) or even reflection (for @mhshams proposed scenario methods) and define rules how to

populate()

the tree and how to

transform()

it. then

traverse()

will provide something like a visitor pattern and provide information which kind of node it is (

SPEK_GIVEN

,

SPEK_ON

, ...).

@Czar has left the channel

I hope this model is flexible enough to e.g. allow data driven testing with data tables like Spock's

where:

block.

hmm, in the current implemention something like hierarchical expressions

given("...") { 
    given("...") {}
}

and direct assertions (like Spock's

expect:

)

given("...") {
    it("...") {}
}

are not supported.

interestingly, within the

given()

expression it is possible to call another

given()

, but this expression will be ignored.

Howdy all

How do I spek better than this