it breaks reporting, I guess it has special meaning in JUnit.

@kirillrakhman: mostly like JUnit reported doesn’t expect anything that is illegal for java method names

my usecase was the decimal separator of a double, too

I simply replaced it with a comma but it's weird when you hit the error for the first time and can't figure out what's wrong

parametrized tests are so easy with spek 😍

Could be great to put a parametrized sample in the doc

Hey guys, @hhariri and I were discussing about how to get feedback on new features we are pushing to spek. I proposed to introduce a meta annotation

@Experimental

to spek. Any public API marked with this annotation may be subject to incompatible changes, or even removal, in feature releases. New features added will be marked as experimental at the beginning. Based on your feedback the feature can be removed or changed in a backwards incompatible way in the next releases. Let me here your opinions about this 🙂

@raniejade: Have you thought about using the JUnit 5 API feature notations (https://github.com/junit-team/junit5/blob/master/junit-platform-commons/src/main/java/org/junit/platform/commons/meta/API.java)? There is an open PR and discussion into exposing it publicly (https://github.com/junit-team/junit5/pull/317), which might be another possible option. I have looked for similar functionality in other libraries instead of writing my own, and I also found https://yetus.apache.org/documentation/0.3.0/audience-annotations-apidocs/ which haven’t yet been published to mavenCentral or jcenter

@mkobit: yep, but it would tie up spek to JUnit 5. The current setup is we have a spek-api and spek-junit-engine. Only the spek-junit-engine depends on JUnit 5, wouldn't want to bring that dependency on spek-api

@raniejade: I've never found

@Experimental

a satisfying solution since you can't really describe which annotation it applies to (and as a matter of fact, the Javadoc in that source says that all annotations on the class become experimental). I've been wondering about a different approach that might be more drastic: whenever you introduce a new annotation that's experimental, add an attribute

experimental

to it and force users to set that attribute to

true

. If they don't, blow up. This makes it clear to everyone that this code is using experimental features. When the annotation becomes stable, remove

experimental

, which will cause all the current code to stop compiling, which is also a desired effect.

@cedric: I'm kinda lost, what do you mean by adding a new annotation? Was talking about adding

@Experimental

to new features we publish.

If that feature is an annotation, instead add an

experimental

attribute to it

Ahhh

Okayy 🙂

If you want to use it, you have to

@TheNewAnnotation(experimental = true)

, kind of a way to make people acknowledge they realize this is a work in progress

and document that as well for readers.

Might be a good option.

Interesting idea, but what about features that adds new methods, classes etc?

Does Spek work well with Android?

Hello! I am interested in contributing to Spek, but I’m not entirely sure what needs some extra work. Could someone point me to a ticket or issue I can tackle?

@connorlay: great. A good place would be the issues marked with release tag on GH

@jasper: please define “well” 🙂 It works for jvm and instrumentation tests, reporting and IDE support could be better, but usually enough to use it

@artem_zin: 👍 Got it working. Thank you.

@jasper: few things I’d like to know when we started using Spek: * Spek runs under JUnit4 runner, so it works everywhere where JUnit4 works: jvm and instrumentation tests * You’re passing one big closure to Spek, so every code execution inside of it happens once except for special DSL blocks like

beforeEach

* Don’t use special symbols like

,.(/

in the names, JUnit4 reporting can’t handle them well * Each parent

beforeEach

will be invoked for each

it()

* Use functions with

f

prefix to execute only one branch of Spek tree (since IDE doesn’t detect separate test cases)

Thank you again. `f`ocused speks are nice, however it will be nicer when the IDE can run single specs.

`f`ocused speks is only a temporary hack, until we get some first class IDE support.

Android people, has anyone tried the jack toolchain? Does it fully support java 8?

@raniejade: better to ask it in #C0B8M7BUY

Android people who uses spek 🙂