Tuesday, July 12, 2011

Mock Objects with Spock Screencast

This screencast demonstrates how to use Spock testing specifications and Groovy for mocking and stubbing behavior in unit tests. It covers creating the mock object syntax, setting expectations, verifying and spying on results, and argument matchers.

If you have any issues with video playback, then trying viewing it from the JBrains.tv website

Here are some useful links to read for this webcast:

I've made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I've done:

Phew, that's a lot of self-promotion :)

The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

Thanks for watching, and leave a comment!


id said...

The second test is wrong. In the when, you are using
instead of

So the order is never filled but you don't notice because you're checking that the remove is never called.

Christian said...

Thanks for taking the time to do this presentation.

Quick question: Are you disabling static code analysis in IntelliJ in lieu of some other mechanism (codenarc)?

I see that your code isn't causing any rules to fire where mine does for the identical code. This is especially noticeable when using the wildcards.

We have recently moved to Spock and I am finding that the IntelliJ static code analyzer complains a lot about things that are hard to ignore globally like compatible types, closures, etc.

I like having at least the default set of analysis rules enabled. We do also have codenarc running during our builds to help identify other violations. Is there a way to tune down IntelliJ via module or class name perhaps?

Thanks - Christian

Hamlet D'Arcy said...

Hi Christian,

During the screencasts I do disable static code analysis. If I'm trying to explain something about Spock then I feel like seeing an inspection warning would be distracting.

However, I share your problem. The Groovy language is getting more and more flexible, which means IntelliJ IDEA is having a harder and harder time making sense of things. It's a shame, really. I don't have any solution.