This presentation is about how to change a team’s attitude towards writing automated tests. The talk covers the same case study as Groovy vs Java for Testing, adopting Spock in MongoDB, but this is a more process/agile/people perspective, not a technical look at the merits of one language over another.

Resources for my “Is Groovy Better Than Java for Testing?” talk.

In the last two articles on Spock I’ve covered mocking and stubbing. And I was pretty sold on Spock just based on that. But for a database driver, there’s a killer feature: Data Driven Testing.

In the last post I talked about our need for some improved testing tools, our choice of Spock as something to spike, and how mocking looks in Spock.

As that blog got rather long, I saved the next installment for a separate post.

We’re constantly fighting a battle when developing the new MongoDB Java driver between using tools that will do heavy lifting for us and minimising the dependencies a user has to download in order to use our driver. Ideally, we want the number of dependencies to be zero.

And now, after an absence of several weeks, you get to see how long it takes me to write some of these posts.

I was putting up the Christmas decorations one Saturday when my worst fear was realised¹ - one of my three strings of lights was not working.

The first two went up fine. The third lit up when I plugged it in, and in less than a second went out. Curses. This is not what I wanted, this was supposed to be a short exercise in making my tiny little flat look festive.

So I set about the tedious task of starting from the end closest to the plug and replacing every bulb, one by one, with a spare one to see if it magically lit up again. When it doesn’t, you take the spare back out and replace it with the original bulb. I remember my parents going through this ritual every Christmas, the tediousness of this activity is more memorable than the fleeting joy of shinies.