Spek: Support table driven tests

[geoand]

Greetings!

Are there any plans to support table driven tests like the ones implemented in Spock using where or the JUnit Parameterized tests?

Thanks!

[raniejade]

No plans as of the moment, but nothing stops you to do:

(1..3).forEach {
   describe("$it") { ... }
}

[geoand]

Thanks for the prompt response!
Yes, for simple use cases the code above would suffice.
Of course for more complicated cases the code would probably be a lot less readable.

[artem-zinnatullin]

The idea here is to run each combination as separate test and when
something fails — show exact value(s) that caused the problem.

There is a Burst from Square that works with JUnit and the core combining
module is not tighten to JUnit so maybe you can reuse it.

On Tue, 7 Jun 2016, 10:39 Ranie Jade Ramiso, [email protected]
wrote:

No plans as of the moment, but nothing stops you to do:

(1..3).forEach {
describe("$it") { ... }
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/spek/issues/91#issuecomment-224203753, or mute
the thread
https://github.com/notifications/unsubscribe/AA7B3Nx22vVOCRzcIEOLrOZqkS4bdUNlks5qJSAZgaJpZM4Ivo14
.

[geoand]

@artem-zinnatullin With the code snippet provided above by @raniejade, the test report / IDE would report on three different tests run, because of the different describe blocks.
Although it's not an optimal solution IMHO, it is viable in some cases

[raniejade]

Actually, I prefer creating separate tests per data (row). When using spock I always use @Unroll, it's easier to see what values caused the problem.

[russel]

I have been a fan of table-driven testing, but am rapidly seeing this as inferior to the random generation approach associated with property-based testing. You can almost do this with Spock, but KotlinTest, and Specks are doing much more the QuickCheck thing, which include shrinking – many claim this is a critical feature.

[hhariri]

+1 on Property-Based testing. This is something I want to bring to Spek.

[raniejade]

Property-based testing is new to me, what's the difference and advantage against table-driven tests?

[russel]

See QuickCheck in Haskell (and many pter languages that have copied it), and Hypothesis (originally a Python thing but now also a Java thing, and if usable from Kotlin, the winner in the test framework war). Also there is KotlinTest which already has property-based testing.

It is about not having to use manually constructed tables, but instead large numbers of automatically generated data. Instead of testing a few cases manually, you test properties of the program with automatically generated data. It is the future of integration and unit testing; example based testing is still needed a bit but very rarely.

If Spek and KSpec are to compete in this game, they need to be at least as advanced as Hypothesis and KotlinTest in this.

[raniejade]

Spek and KSpec are joining forces, both are still in the early stages of development. We are still working on the first release, this will eventually happen some time in the future (we don't have a definite roadmap yet).

[russel]

I had heard whisper of the coalescence of the Spek and KSpec efforts, which I think a good thing. Any decision on which name going forward?

On the one hand I would like to see KotlinTest in the mix so there was only one test framework, making it easy to market and build a team to move it forward. On the other hand having a multiplicity of frameworks can be a positive statement, unless the language is C++ as they take "make your own framework" to extremes. Currently I am lining up behind KotlinTest simply because it supports property-based testing. Oh and Spock because it's Groovy :-)

[raniejade]

Spek, because bacon is :heart:. Anyways, I can imagine the order of things that will happen. Firstly we need to table-driven tests (manually set the inputs), then property-based testing can follow.

[sksamuel]

Scala does ok with two test frameworks. A spec type one (Specs2) and a "JUnit" type one (ScalaTest). So I think Spek and KotlinTest could live side by side quite happily each offering something different. For example, I'm personally not into _specifications_ and prefer writing more straightforward unit tests, and I know other people who think the opposite.

[raniejade]

Hey guys, anyone can help us with #146? :)

[raniejade]

Resolved in #146.

[breandan]

Any updates on property testing? Not just grid search, but with shrinking support to find the minimal counterexample? Would like do property testing, but KotlinTest is the currently only framework that implements it correctly. @hhariri