did you face any problems?
I used it and love it! But it has drawbacks also. Have to go out right now, will give you detailed info later today
Used it with grails mostly. Also used it java project that was a small part of larger ecosystem. Well, advantages are obvious: - it runs on top of junit (implemented as junit runner/extension), so you can mix spock with junit, so you can just try it in existing project and see how it goes (spock2 - junit5, spock1 - junit4, mix different versions is not a problem, but requires some build system configuration) - mocking in spock is a breeze - powerful, flexible, and concise - data driven tests are much more pleasant to use than ones in junit, and more important it's much easier to comprehend those when you read tests other developers written, compared to junit - has some nice in-built "extensions" (don't remember exactly how they are called, one most notable I remember is @Timeout(...)) - you can build your own extensions, and what's more important - it's very easy to do; I remember building something like this https://vertx.io/docs/vertx-unit/java/#_asynchronous_testing for testing async code, so application of it would be @Async(steps = 3) def "some test with 3 async steps verifications"(Async async) { doSomething().andThenOnAnotherThread(() -> async.success()); // ... } Building such stuff was a breeze, it needed very little effort to ingtegrate with spock. - groovy power asserts are probably the most important advantage. They are just super-awesome. Even assertj with all it's bunch of cool handy methods out there and readable error messages is nothing compared to groovy power asserts. Groovy asserts are more readable, require zero effort from you in terms of learning some api, and present you what you exactly need in 99% of cases. You know how they said in the movie - unfortunately, no one can be told what groovy power assert is. You have to see it for yourself. Now to the drawback. And here I can list only one, but it's huge. It is applicable only if you have non-groovy project. You have java project. You have java devs. You need to write tests for java code. And you decide to use groovy testing framework. Now you have two problems - you need to write tests and all your java devs have to learn groovy, at least the basics. And the thing is the more they learn - the more they use, and you become more and more dependent on groovy skills. So now when you need to find one more dev on the market you would need to have groovy in their skillset. This won't be a problem at all, if you'll manage to not use lots of groovy specific features in tests, but I wouldn't rely on it.
Thank you for your comprehensive feedback! Can I quote and refer to you? Have you used this Framework in SAP Commerce (Hybris)? I ask this because the project where I propose to use it is a SAP solution.
Yep, sure. But be careful to not make such decisions based only on feedback of some random guy on the internet)) Have no idea what this SAP is, never worked with it. So I can't give any advice here. But imho, if the *repository* (smallest isolated indivisible unit of building) where you want to use it is big enough and there will be more than 4-5 devs working with it, I wouldn't use spock. Because of the last point in my description - you would introduce one more technology/language that developers usually are not familiar with.
Обсуждают сегодня