I just joined this group and I have a question abo...

# getting-started

[Srikumar]

I just joined this group and I have a question about Testing frameworks in Kotlin. I find Spock's data driven testing very useful and was wondering if there was anything similar to that in Kotlin frameworks? I have checked out Spek, but found its data driven testing (parameterised) to be too restrictive and verbose

[tddmonkey]

You can carry on using Spock with Kotlin code

[Mike]

JUnit Jupiter works very well with Kotlin and has good parameterized tests.

There’s KotlinTest, and Spek 2.0 that both have ways of doing parameterized tests.

And finally, a newer framework with a different approach:
http://oneeyedmen.com/my-new-test-model.html

Or Spock can/does work too.

[Srikumar]

I am at the moment.. but I do see a few issues with Spock..
1: I need to declare a bunch of classes open
2: Alternatively, I could Annotate a few classes using the allOpen compiler plugin..

But either of these two will violate encapsulation principles and I am not entirely about this. So, i was wondering if anyone else out in the wild had a better option

[Srikumar]

@Mike -those are some interesting options,.. will look into those and see if any of them solve the problems I am talking about.. Just to be clear - Spock does the job at the moment and thats what I am using extensively in my project. But it doesnt hurt to look for better alterntives IMHO

[Mike]

What do you need to open? For mocking?

And there’s also a #test channel. Someone just asked about a Spock equivalent in Kotlin…

[Mike]

Because if you need to open something for Spock/Groovy, then you’ll likely need to do that for others as Groovy doesn’t even respect private.

[tddmonkey]

I’ve been using Spock extensively for our Kotlin codebase and never had to open anything

[Srikumar]

#test sounds like a more appropriate channel for this discussion,.. thanks chaps!
@tddmonkey - I am required to open classes which are not implementing an interface for Mocking.. since Spock uses cblig to mock classes by extending them. I am surprised that you didnt have to do that .. ever!

[tddmonkey]

I don’t mock concrete classes, ever. It’s much better for your design to introduce an interface, but we can discuss that in #test

[Mike]

Mockk? although it feels a bit ‘weird’ to introduce a mocking framework when Spock has one built in.

Or as Colin suggested, build with interfaces. Personally, I don’t like introducing interfaces just for this. If there’s only one implementation, then it feels like redundant code to me…

See you in #test.