Preface

Pete Hodgson used to joke that building your own mocking framework was a rite of passage for ThoughtWorks developers. Those days are past, not because ThoughtWorks doesn’t care about testing anymore (we do, very much), but because the tooling around testing is a lot better, and because we have more interesting problems to focus on nowadays. In the winter of 2014, I had a testing problem, and it turns out that not being able to test prevents you from focusing on those more interesting problems.

We had adopted a microservices architecture but were limited by some of the legacy service code we were strangling out. The idea of service virtualization—using tests to mock up downstream network dependencies—was not new to us, even if the term wasn’t common in the open source world. It seemed like every time a new developer joined the team, they recommended using VCR (a Ruby tool) or WireMock (a Java tool) to solve the problem. Those are great tools, and they are in great company. By that time, ThoughtWorkers had contributed a couple more quality tools to the mix (stubby4j and Moco), and tools like Hoverfly would be coming soon. You wouldn’t have been wrong to pick any of them if you needed to virtualize HTTP services.