• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java Testing with Spock book question

 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the ranch!

Would you use spock in legacy project with mockito and junit? If yes, what's the reason to use it over those frameworks?
 
Author
Posts: 16
5
Spring VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

Yes! Actually this is the scenario I had in mind when I wrote the book. This is also the way I have used Spock in my own projects.

First of all, because Spock tests can be run with existing tools (IDE's and build systems) it is very easy to have both Spock and JUnit tests in the same project and run them together.
This allows you to experiment with Spock without throwing away your JUnit tests.

Mockito versus Spock

Compared to Mockito, Spock has some nice features.

For example, when using argument matchers in Mockito you have to use them for all arguments of a method.
There is a big warning "If you are using argument matchers, all arguments have to be provided by matchers." in the Mockito docs

http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html

Spock does not suffer from this limitation and you can mix and match argument matchers and specific values as you wish.
Also I find the syntax of argument catchers in Mockito very confusing compared to the Spock way (that uses Groovy closures)

Here are some examples from chapter 6 (which is devoted to mocking and Stubbing with Spock)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter6/src/test/groovy/com/manning/spock/chapter6/mocks/ArgumentVerificationSpec.groovy

Mockito versus JUnit

Compared to JUnit the advantages are too many to list in a single post (actually that is the whole content of the book)
The biggest revolution I think is the way Spock handles parameterized tests and all the options is offers (chapter 5 of the book)

For comparison here is a parameterized test in JUnit
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter3/src/test/java/com/manning/spock/chapter3/nuclear/NuclearReactorTest.java

and the same one in Spock (notice the number of statements)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter3/src/test/groovy/com/manning/spock/chapter3/nuclear/NuclearReactorSpec.groovy


Also Spock gains a lot of points just from using Groovy

Here is an example of test data creation in Java (for a JUnit test)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter2/src/main/java/com/manning/spock/chapter2/assets/SampleShipRegistry.java

and the same in Groovy (for a Spock test)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter2/src/main/groovy/com/manning/spock/chapter2/assets/GraphBuilderDemo.groovy


I will let you decide which versions you prefer :-)

Anyway, let's just say that all the cases where I have used Spock were existing legacy projects with Mockito and JUnit exactly as you describe. The only case where I used Spock on brand new code was on a small Grails project (so I had full freedom)

Kostis
 
Krystian Kowalski
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your answer
I got your point, those tests are much more readable, easier to maintain and parameterized tests... it looks really good. Maybe example with data creation in Java is too exaggerated to show how java can be verbose, because you can use static factory methods or builder.
Anyway, i will give it a try for sure!

One more question: what about mocks in spock? Are they all "Nice"?
 
Kostis Kapelonis
Author
Posts: 16
5
Spring VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Krystian

Yes, mocks in Spock are "nice". Nothing bad will happen if you called a method that was not stubbed.
You will just get an empty value (whatever empty means in that context)

Enjoy!
 
reply
    Bookmark Topic Watch Topic
  • New Topic