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
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)
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)
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)
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"?