This is a cool approach to finding bugs in non-deterministic services. Basically, each request is played against three servers: one running the code to test, and two running known good code. If the variation in responses between test:good is no different than the variation between good:good, you can assume that no regressions are present.
When we moved the Twitter web frontend from the RoR stack to the Scala stack we used a similar tool built into the proxy we called Tap Compare. The new thing in Diffy is to use two calls to known good services rather than one call to filter out the non-deterministic bits. With tap compare we basically had to whitelist those parts of the page. This kind of strategy is pretty powerful and you will likely find lots of places in your infrastructure where it makes sense to use it.
ahem "Build failing"....
not the greatest way to start off my interaction with a tool that's supposed to find bugs.
coverage 13% doesn't help much either.
Contributions welcome :)
We've been using diffy to test diffy :)
Just kidding. Contributions welcome.
Attributed to network failure while downloading build dependencies.