6.6. Summary

• Fake classes can be used in unit tests instead of real classes. They’re needed in several cases, such as when the real implementations are slow or have severe side effects.
• Spock supports two kinds of fake classes: mocks and stubs. Stubs are fake classes with preprogrammed behavior. Mocks are fake classes with preprogrammed behavior that can also be queried at the end of the test for their interactions.
• Spock can mock/stub both Java interfaces and concrete Java classes.
• Canned responses in stubs are programmed with the right-shift operator: >>.
• Preprogrammed responses can be differentiated according to the argument method or the number of times a method was called.
• The unsigned right-shift operator (>>>) can be used to stub sequential calls of the same method with the same arguments.
• The underscore character acts as a universal matcher in Spock when you don’t care about the exact content of a call. It can be used to match arguments, methods, classes, or even the number of times a method was called.
• By using Groovy closures, a stub can be instructed to throw exceptions, run custom statements, or perform any other side effects.
• Groovy closures can also be used in stubs to create dynamic responses according to the argument passed to the stubbed method.
• It’s possible to mix the underscore operator, fixed arguments, and Groovy closures in the same stubbed method call.
• Stubs/mocks can return other stubs/mocks. Recursive stub creation is possible if legacy production code requires it.
• In Spock, mocks are a superset of stubs, but for readability, you should use mocks only when you want to verify the interaction with the class under test. For fake objects that are used only for their responses, you should use stubs.
• By default, the order of mock verifications inside a then: block doesn’t matter. You should use multiple then: blocks if you care about the order of verifications. Each then: block will be evaluated in turn.
• It’s possible to verify the number of times a method was called. Using zero as cardinality means that you expect that a method was never called. Using the underscore character means that you don’t care how many times it was called.
• You can verify arguments of a mocked method to ensure that they weren’t null, or that they had a specific type.
• You can use Groovy closures as argument catchers to perform further validations on specific arguments of mocked methods.
• As with JUnit/Mockito, Spock is more easily applied to Java code that’s designed to be testable in the first place.
• With Java classes, Spock can’t mock private methods and static methods/objects. You should refactor your Java code first before writing Spock tests, or use PowerMock if you’re desperate.
• Care must be exercised with the underscore character. It can result in lenient tests that let subtle bugs slip through.