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)
Here are some examples from chapter 6 (which is devoted to mocking and Stubbing with Spock)
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
and the same one in Spock (notice the number of statements)
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)
and the same in Groovy (for a Spock test)
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)