no, I feel closer to

describe

and

on

@adambl4 except in your case you would place your

beforeEach

as close as needed; I look at it as a helper for de-duplicating setup code

what the usecase of

afterEach

that will also be executed after each

on

?

I mean, maybe we don't even need

beforeEach

and

afterEach

¯\_(ツ)_/¯

that smell of sarcasm

That could be

each {
   before { … }
   after { … }
}

I loved the way it works now. To me it seems the most logical and uniform with what we are used to from JUnit.

@Before

(

beforeEach

) executes before each

@Test

(

it

)

And I want a clean setup for each test, so all common setup can now be extracted to the outer groups.

So let’s say I’m testing a presenter with a view. I can do something like this.

@User uploaded a file: Untitled

Now I have a clean setup to run my test. Instead of doing something dirty like

Mockito.reset(mainView)

to reset my invocations.

@eddie I do agree with your argument

if each indentation level can be thought of as a new "scope", then any

beforeEach

should apply to each of its siblings non-recursively

I have a double feeling with both. Because #2 would require me to add an additional

beforeEach

in my inner group

beforeEach{
    mainView = mock<View>()
    mainPresenter.attachView(mainView)
}

May be just call it

beforeIt

?

I think we need to also think about the naming here. Cause currently it's not entirely clear.

I am a spek newbie and so far I think it is a very nice framework! One feature I’m curious about is the ability to inherit fixtures. As an example, let’s say for almost all of the project's specifications, I need a common setup and teardown. This could be tasks such as loading data into a database and then deleting the database after the test. Is there a way to do define these fixtures somewhere once, then reuse? Currently, I just have the code for these setup/teardowns defined in util objects, but was curious if there is a way to not have to explicitly call them from within each group’s fixtures. Thanks for the assistance.

AWESOME!

@adambl4 I think I’m missing something. Is there possibly an example somewhere showing that feature?

@michaelvaughan there is not really a good example

just call that fun in a Spek test body

I have a speacker deck but without the text it’s probably not going to do much for you.

@adambl4 ah ok, cool. Thanks for the help!

Hi Spekkers, I have just tried converting a simple test to Spek. It runs fine from IntelliJ but when running Gradle test (with the Junit 5 engine as per Spek docs) it doesn’t appear to see/run my spec. Can anyone point out why? https://github.com/michaelbannister/tdd-template/tree/roman-numerals-kotlin-spek (N.B. this is a branch, if you clone you’ll need to checkout roman-numerals-kotlin-spek)

(In return for help I can offer only gratitude, I’m afraid. I’d love to contribute to Spek but don’t have the time or the cleverness)

@michaelbannister but you’re not using junit 5?

testCompile "junit:junit:4.12”

I’m not sure because I’ve only used it for Android but because we use junit 4 in Android we have to annotate our test with

@RunWith(JUnitPlatform::class)

@michaelbannister what @simon.vergauwen said is correct. I also solved this problem just a few weeks ago with the same suggestion. You can see the example of

build.gradle

and Spek classes from my repo here. https://github.com/taskworld/kraph