Hey all! There's quite some notable changes in

2.x

. Firstly, dependency group id and package prefix is now

org.spekframework.spek2

. Idea is to allow running

1.x

and

2.x

tests side-by-side. For DSLs, we decided to split it into two styles (https://github.com/spekframework/spek/issues/374): Specification (rspec, Jasmine - https://github.com/spekframework/spek/issues/394) and Gherkin styles (https://github.com/spekframework/spek/issues/396). A glimpse of the two styles below:

class SetSpec: Spek({
    describe("a set") {
        val mySet by memoized { ... }
        
        context("when empty") {
            it("should have a size of 0") { ... }
            it("should throw an NoSuchElementException when ...") { ... }
        }
    }
})

class MyFeatureSpec: Spek({
    Feature("My Feature") {
        val myFeature by memoized { ... }
        Scenario("Some scenario") {
            Given("some precondition") { ... }
            And("another precondition") { ... }
            When("some action") { ... }
            And("another action") { ... }
            Then("some testable outcome") { ... }
            And("another testable outcome") { ... }
        }
    }
})

The DSLs are built on top of Spek core (

group

,

action

and

test

), this means that you can implement your own DSL. On the IDE side, there will be a new IntelliJ Plugin. We have introduced (https://github.com/spekframework/spek/issues/246) several meta annotations for IDE consumption. Marking an extension method with

@Synonym

will tell the plugin that said method is runnable. Making

describe

runnable in the IDE for example:

@Synonym(SynonymType.GROUP)
@Descriptions(Description(DescriptionLocation.VALUE_PARAMETER, 0))
fun GroupBody.describe(description: String, pending: Pending = <http://Pending.No|Pending.No>, body: Suite.() -> Unit) {
    createSuite(description, pending, body)
}

Lastly, another major goal for

2.x

is to prepare for multiplatform support. We have separated the core parts of Spek into a common module and platform specific code (runners for example) into its own module. Everything that I have mentioned, except for the DSL changes, are in the

2.x

branch already. Running common module tests from Gradle is already supported, see https://github.com/spekframework/spek/tree/2.x/integration-test. The IntelliJ plugin will also support it (with some limitations) once https://github.com/spekframework/spek/pull/407 lands. Finally, I'm very sorry for the delays, there has been a lot of changes in my life these past few months that I had to prioritize first.

Great news! Thank you for all your work!

Yes, this all sounds exciting I like the direction spek is headed. Thanks for your work and look forward to using 2.x

Hey guys! Requesting for comments: https://github.com/spekframework/spek/issues/411 🙂

Hi all, Is there any possibility to write/run androidTests using Spek? Any information about it would be helpful, thanks.

Currently there is no way to run instrumented tests with Spek, iirc

Planning to drop SubjectSpek` in favor of the new

memoized

in https://github.com/spekframework/spek/issues/411, it is basically

memoized

under the hood. It feels a bit redundant now since you can also do TCK-like tests with

memoized

. Thoughts?

Not totally clear from that example what the actual initialization of

loginService

would look like. The hole I always found in

SubjectSpek

for TCK tests was that it’s not possible to reference dependencies (defined in abstract base spec) in a

subject

block in a derived spec. Is that no longer a problem?

(Maybe it is clear, but I only just woke up)

Real world example of what I mean. This abstract test has a subject with dependencies the test needs to mock/stub/control https://github.com/spinnaker/keiko/blob/master/keiko-tck/src/main/kotlin/com/netflix/spinnaker/q/QueueTest.kt#L38 With SubjectSpek there would not be a way the implementation https://github.com/spinnaker/keiko/blob/master/keiko-redis/src/test/kotlin/com/netflix/spinnaker/q/redis/RedisQueueTest.kt#L41 could reference those dependency variables in order to initialize the concrete subject instance.

You should be all be to access dependencies as well, provided they are

memoized

.

object QueueSpecs: Spek({
    fun Suite.queueTests() {
        val queue by memoized<Queue>()
        val clock by memoized<MutableClock>()
        val deadletterCallback by memoized<DeadMessageCallback>()
        ...
    }
    
    describe("RedisQueue") {
        val clock by memoized { MutableClock() }
        val deadLetterCallback by memoized { ... }
        val queue by memoized { createQueue(clock, deadLetterCallback) }
        
        queueTests()
    }
})

Sounds great

How do we make test suites for multiple environments with Spek?

@dave08 might be hack-y feeling, but you could just declare a new variable in the scope of the

on

if it’s just a one-off anyway

Am I doing something wrong?

it seems like if I use println, it executes the given before the every?

I need the something.doThis() to return something different for each

given

, but retain that for the

on

and the

it

And running

every

on the same function twice gives an error unless the mock is reset...

and something is being passed to another memoized class.

Anyone using Spek on Android Studio 3.2 Beta?

Either that or publish a 1.1.20!

Good example why you shouldn’t use wildcards for dependencies

That’s true, except that with Gradle 4.8 it’s not automatically a bad idea because dependency locking

I would like to see spek moving forward (I would like to use it for JS). Can I help somehow?

@Hamza uploaded a file:

@Hamza uploaded a file:

@Hamza do you have the plugin installed? https://plugins.jetbrains.com/plugin/8564-spek

😅

no

i’ll let myself out