Spock 1.2 Annotations for Spring Integration Testing

@SpringBean, @SpringSpy, and @UnwrapAopProxy are new annotations in Spock 1.2 that make it easier to inject mocks into the Spring context when doing Integration testing. These can greatly simplify your code from using a @TestConfiguration approach, though there are some drawbacks too. If you’re not familiar with the Spock 1.1 @TestConfiguration method, take a look at the original Spock Spring Integration blog post from Derek Eskens.

@SpringBean

Let’s start with the easiest new annotation @SpringBean. This annotation will tell Spock to add the mocked bean into the Spring test context. To use it you will need to explicitly create the Mock() and include a defined type (instead of using `def`)

@SpringSpy

Similarly, @SpringSpy will wrap a Spy around the bean that Spring creates and puts into the context. For most cases it is simple to just use @SpringSpy in place of @SpringBean.

It becomes more complicated when trying to Spy a Spring AOP Proxied bean. @Validated services are one type of proxied object, as Spring wraps the class to perform the validation.

Without unwrapping the AOP proxy, the error you see in Spock will be very puzzling:

@UnwrapAopProxy

@UnwrapAopProxy is a new Spock 1.2 annotation for easily unwrapping the proxy to use the spied object.

While @SpringBean and @SpringSpy make it very easy to Integration Test, the one drawback is that Spring will create a new test context for each test and will not try to cache and reuse the context between tests. So for very large applications with many tests this can be quite slow. In those cases you will still need to resort to using a reusable @TestConfiguration class.

Manual AOP Proxy unwrapping

In those cases, you will need to manually unwrap the AOP proxy for spying. This can be done using AopTestUtils.getUltimateTargetObject() from the spring-test package:

Spock 1.2-SNAPSHOT

As of this blog post writing in May 2018, Spock 1.2 is still a SNAPSHOT and has not been fully released yet. So to pull in the snapshot you’ll need to use the snapshot repo in your gradle (or maven) file

Hopefully this was a helpful intro to the new annotations available in Spock 1.2. You can try them out in a full source repo with tests by cloning the github repo https://github.com/jeffsheets/spring-spock-integration-testing/tree/feat/mockSpringCglibProxyValidated.

About the Author

Jeff Sheets profile.

Jeff Sheets

VP - Technology

Jeff has developed Java, Groovy, Grails, and Javascript web apps for industries as varied as Defense, Energy, Weather, Insurance, and Telecom. He is a co-organizer of the Omaha Java Users Group. Jeff has worked on Grails projects since the Grails 1.3.x days, and has experience with production Groovy code as well as Spock tests and Gradle builds. His latest focus has been on AngularJS and Spring Boot applications using JHipster. Jeff also enjoys volunteering at local CoderDojo events to teach programming to our next generation.

Leave a Reply

Your email address will not be published.

Related Blog Posts
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]