Spek is not really designed to apply annotations on fields in the test, usually what we do in practice — use separate “test environment container” class

right, that makes sense

@artem_zin example java code

ie:

UsersApiSpec : Spek({

  val env by memoized { Environment() }

  it("does not access db by default") {
    verifyZeroInvocations(env.dep1)
  }
})

class Environment {
  
  dep1 = mock<Dep1>()
  dep2 = mock<Dep2>()
}

from what I last heard they were working on support for spring

mhm,

@RunWith(SpringRunner.class); @SpringBootTest

I've never seen that style before. Is it in the spek guide?

SpringRunner

uses

JunitRunner

btw

not in the guide (yet?)

@RunWith(SpringRunner.class); @SpringBootTest

if they opened API of classes used by the implementation of

SpringRunner

you should be able to programmatically replicated that for Spek

Even if they didn’t open exact implementation classes you should be able to replicate that

@snowe something like this

@artem_zin uploaded a file: Untitled

dang.. that's so boilerplatey though.

Not really, one of the Spek benefits is that it greatly reduces “setup” code in compare to JUnit, it allows you to split assertions into separate test cases, make reports more readable (in IDE, html one is still messy…)

This is literally the definition of boilerplate

init {
        // Configure Spring DI, it's 100% possible
        SpringDi.inject(this)
    }

val env by memoized { Environment() }

With plain junit if I want to pull it into another class I can, I still use autowired, I just extend or implement that class.

I’m definitely not saying that “Environment” setup is not boilerplatish 🙂 it is What I’m saying is that later Spek saves lots of boilerplate and complexity that JUnit’s model have for

@Test

cases 🙂

gotcha. yeah it does. that's why I'm trying to get this working so we can use it 😂

haha 😄

well, I hope that helps 🙂 Personally, I find this separation of

Environment

very useful, it clearly separates tests from env setup/deps resolution

I won't knock it until I try it. Hopefully it will improve our testing

I was playing around with Spring spek integration a couple of months ago. https://github.com/spekframework/spek-spring-extension

@ContextConfiguration(classes = arrayOf(MyConfiguration::class))
object MySpec: Spek({
    val context = createContext(MySpec::class)
    val foo: Foo by context.inject()
    
    it("blah blah blah") {
        foo.doSomething()
    }
})

@raniejade but then you have to create a Configuration, which is kinda the antithesis of spring boot.

some doubts about spek - is there a way to combine instancefactory with lifecycle listener?

Are there special consideration when trying to debug to a breakpoint with a test run through spek? I’m using a

build.gradle.kts

instructing intellij to execute the gradle

test

task in debug mode

nothing special from Spek here, you just need to attach debugger to the JVM that runs the code

easiest way would be to run tests in debug mode in IntelliJ, but if you need to start tests from command line I’d try running gradle with

--debug-jvm

see

<https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_test>

Hmm, I’m not sure what else to look into. I’m use debug in intellij, but can’t seem to get my breakpoint to stop, but the tests continue running

@raniejade did you try custom class loader with @CreateWith? https://github.com/spekframework/spek/issues/115. How can I run a test on different class loader since it throws classcastexception

I have written a sample robolectric integration but can't cast the subclass to spek since the classloader is different - https://github.com/bangarharshit/spek/commit/6a5cf6ef66a914a04059e8b16796d9d4b99385bb