I use TestNG. It is the most convenient to use (an...
# server
j
I use TestNG. It is the most convenient to use (any public method inside a test class is considered a test without annotating it). Also back in the time it allowed me to run tests many times in each run to do simple stress tests. However I guess JUnit 5 improved a lot, although to me it is still more complicated than TestNG. For acceptance tests I use Cucumber, but you really should take a look to Spek 😉
g
How about Spock ?
👍 1
j
I used it some time ago, but I guess it is very tied to
Groovy
And because of that, it is slower
g
Yes , isn’t groovy more expressive when it comes to writing tests?
👍 1
j
However, tests written in Spock are highly readable, but I would use Spek to work with Kotlin
g
Is Spek similar to Spock and is spek matured enough to be used now?
j
You can compare syntax with this: https://www.spekframework.org/gherkin
g
Thanks @jaguililla
j
I would certainly use Spek, but if it is production ready or not is a decision for you to make 😉
Welcome… I hope it was helpful
t
We use Spock exclusively to test our Kotlin code. The readability and diagnostics are second to none. My only issue with it is the lack of language iterop - e.g. Groovy has (sort of) named params and defaults, like Kotlin - but they’re not interopable. This leads us to creating a secondary data model layer in Groovy to handle conversion
👍 1
m
Personally, I'd forget about Spek, and look at Kotlintest instead. Spek never really took off, and Spek 2 has taken a long time to get out. KotlinTest is similar to ScalaTest if you want a comparison. Allows for different styles, supports Property Based testing, and many other things.
Kotlintest also has very good assertions built-in. Very impressed with it. Spock is excellent from a readability perspective, but Kotlintest is very close.
c
I really like plain Junit5 with #strikt assertions. I have found Sequences to be particularly good for writing parameterized tests, which really help to test my code with lots of data and find all the edge cases
m
JUnit5 works very well, I agree, and is nice as it's an easier transition for an existing Java team. Very powerful parameterized testing and many other things. Hadn't heard of strikt before. Too many assertion libraries created. I tend to stick with AssertJ, again, because it's an easier transition for Java teams, and it's so powerful. If I were to move to a Kotlin one, I'd seriously consider #atrium . But as I say, too many of them, and personal taste.