Hooked on Synthesis

Synthesis is an incredibly powerful tool, but until the Ruby Tuesdays meeting in the ThoughtWorks office last night I didn’t really grasp what it does.

It’s actually quite simple, but it changed the way I think about tests and mocks.

Say you have a Foo and a Bar, and they need to talk to each other so that your system can fly on pink unicorns. In fact, you expect the instance of Foo to tell an instance of Bar to frobble, giving it an instance of Baz to play with, and then, when the frobbling is done, Foo gets an integer back, and the rest is some complex logic that we won’t get into now (flying pink unicorns is difficult, as well as getting ahold of one). In a less noisy language:


No problem there, and it should be fairly quick to make that a green bar. The problem starts when I rename frobble to frob in Bar but forget to change it in Foo. That test/spec/example/whatever we call it these days will still pass, as the expectation is still valid, and foo fulfills it nicely. It’s then up to you to figure out that this expectation has gone bonkers in the first place, and fix it.

What Synthesis does is to tell you that you forgot that. That’s it. Nice readable error message that tells you “hey, Bar doesn’t know about frobble, why did you ask it to do that?”, and fails the test. That opens a great big can of rainbows: when you don’t have to validate every assumption about your mocks anymore, suddenly what people usually call integration testing isn’t as necessary – you can have confidence in your system without having to write tons of fiddly set-up code or double-checking those interactions by hand.