however that’s fine for a single iterable. Something like Spock’s data table would be incredibly useful for more complex scenarios.

@robfletcher: Yeah. And in 1.0 experimental branch right now givenData is dropped, so looking at ways to improve.

Another question: base classes - how useful are they? We’ve been discussing briefly today the possibility of moving entirely to top level functions using Kotlin scripting support.

Also, if you’re playing with 1.0 branch, note that @lkogler introduced the x prefix (i.e. xdescribe, xgiven, etc.) to designate incomplete tests

I looked at

givenData

and found it a bit limiting – the “given” expression is entirely dependent on the

toString

value of the iterable elements

It’s basically as easy to just do

(1..100).forEach { i -> given(“an integer $i”) …

another advantage being that you can use that kind of construct at any level

you can wrap an iteration like that round

on

or

it

just as easily as

given

it doesn’t work so well for multi-dimensional data

you can do it using a list of maps or something but the result isn’t very readable

re: base classes – I like the top level functions idea as it gives me the flexibility to introduce my own base class if I really need to (I can’t imagine why I would but maybe for very involved integration tests with some kind of framework)

okay so

x…

is effectively like an

@Ignore

annotation in JUnit or Spock?

I guess I’ve seen that convention used in JavaScript testing frameworks

I’m not sure how multi-dimensional data could be best handled – Spock does it by overriding the

|

and

||

operators in a certain context and then relying on custom tooling support to make it easy to keep the tables tidy.

There’s something about the simplicity and flexibility of using

forEach

that I find appealing – it’s a lot like how I write JavaScript tests using Jasmine

The changes on @lkogler’s fork look great. One of the limitations I’d run into previously was being locked into a 3-level structure – 

given

,

on

,

it

– and it appears that’s no longer the case. Feels very like Jasmine which I’ve always liked structurally (probably RSpec too but I’m not really familiar with it)

Also great that each

it

has a clean context – that drives me mad in Scalatest

(it’s not the default there, IIRC there’s an optional trait you can include to make it do that)

Next on my wish-list would be diagrammed assertions 😁

Whoa, I've never seen diagrammed assertions before, but I just looked it up, and they're pretty cool!

@robfletcher: Do you think there's any reason to integrate something like diagrammed assertions into the Spek framework? As a general principle I prefer to keep the test-running framework separate from the test assertion framework so that people can mix and match as they please.

agreed, I don’t think it’s a spek-specific feature

I’ve had some discussions with a couple of other Kotlin enthusiasts here about the idea and IIRC the compiler would have to behave a little differently – not really my area of expertise

because the information required to generate the diagram in a similar way to Scalatest’s

DiagrammedAssertions

trait or Groovy’s

assert

keyword just isn’t there

Just tested version

1.0.0

, works very well. My two cents: I like the semantics of "`given` /

on

/ `it`" or just "`given` / `it`". Will Spek allow to choose between

given

/

on

or is it just in spek 1.0.0 to facilitate the transition to

describe

? I would really like

given

and

on

to stay 😉 But if they do, I think they should be an alias with the addition of the keyword at the beginning of the describe string. (e.g. :

given(description, block)

should be an alias to

describe("Given " + description, block)

). Right now, when I use

given("a calculator")

, the test runner displays "a calculator" while I wish it displayed "Given a calculator".

I think the readme suggests they’ll be aliases so you can still use

given

,

on

,

it

.

@salomonbrys: Yeah, it should actually. Do you mind logging an issue? Will look into it.

There might be some issues with that, but better to track and discuss independently on each issue.

@hhariri: https://github.com/JetBrains/spek/issues/74

hello, trying to use Spek in my gradle project, and it seems that the repo can not be updated: https://db.tt/RWjF0900