MEAP Edition Manning Early Access Program Testing Microservices with Mountebank Version 11 Copyright 2018 Manning Publications For more information on this and other Manning titles go to www.manning.com ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank welcome And thank you for purchasing the MEAP for Testing Microservices with Mountebank. The increasingly distributed world of microservices has challenged traditional testing approaches. Mountebank is what’s known as a service virtualization tool – essentially stubbing over the wire – and is tailor made to help you with your microservices testing woes. The good news is that the tool is cross-platform and, because it uses an HTTP API, language-agnostic. It will be helpful to know some JavaScript to work through some of the examples, but we’ll keep the focus on the tool itself and how it enables a broader test strategy. More importantly, experience in automating tests will help you get the most out of the book. Mountebank is about making test automation as easy as possible. The book starts by building a foundation of fundamentals, starting with a recap on microservices and how they require a different testing approach. The second section deep dives into using mountebank, including using record and playback functionality to create realistic test scenarios and post-processing responses. We’ll also show more complex scenarios – those requiring programming mountebank itself or stubbing binary TCP protocols for integration – near the end of the section. I promise you no silver bullets. Mountebank has a place, and an important place, in a microservices testing strategy, but I make no claims of it being a total solution. After we get over some fundamentals of using service virtualization to write automated tests, we’ll get into how to construct an overall Continuous Delivery testing pipeline for microservices that ensures release independences between services. We’ll also look at how to use service virtualization to support a thoughtful performance test strategy that doesn’t require an end-to-end environment. I’m very thankful that you’re here. Your feedback throughout this book is essential to making Testing Microservices with Mountebank the worldwide best-seller we both know it can be. Don’t hesitate to send any questions, concerns, or comments to the Author Forum. I look forward to hearing from you! — Brandon Byars ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank brief contents Preface Acknowledgments About this book About the author PART 1: FIRST STEPS 1 Testing Microservices 2 Taking Mountebank for a Test Drive PART 2: USING MOUNTEBANK 3 Testing Using Canned Responses 4 Using Predicates to Send Different Responses 5 Adding record/replay behavior 6 Programming mountebank 7 Adding behaviors 8 Protocols PART 3: CLOSING THE LOOP 9 Mountebank and Continuous Delivery 10 Putting mountebank in a continuous delivery pipeline ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank 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 there are more interesting problems nowadays to focus on. But in the winter of 2014, I had a testing problem, and it turns out, 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 out 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 one) to solve the problem. Those are great tools, and they’re 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 would not be wrong to pick any of them if you need to virtualize HTTP services. Unfortunately, our downstream service wasn’t HTTP. The fact that new team members kepts suggesting the same type of tooling provided good evidence that the approach worked. The fact that, without such tooling, we were unable to gain the confidence we needed in our tests provided the need for mountebank. Over that winter break, buoyed by red wine and Jon Stewart jokes, I wrote mountebank. This book is about mountebank, but it’s also about testing and about continuous delivery and about microservices and architecture. You may be able to do your job without mountebank, but if you run into trouble, service virtualization may just be able to help you focus on the more interesting problems. ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank acknowledgments The advantage of working for a company like ThoughtWorks is that a lot of people I know have written technical books. The disadvantage is that every single one of them told me writing a book is, like, really hard (thanks Martin Fowler, Neal Ford, Mike Mason). Fortunately, Pete Hodgson wasn’t one of them. He has, however, written several articles, including one on testing JavaScript on Martin Fowler’s bliki. I didn’t really understand it the first 10 times I read it, and, not being a JavaScript developer myself, tried to implement a synchronous promise library based on a naive interpretation of promises. A few weeks later, when I had untangled my frontal cortex from my corpus callosum before realizing what a Bad Idea trying to write my own promise library was, I asked Pete for help. He provided the first contribution to mountebank, showing me how to actually test JavaScript. I felt that was a good thing to know, since I was writing a testing tool. Thanks, Pete. Paul Hammant also never bothered to tell me how hard writing a book is. Unfortunately, he also never bothered to tell me how hard managing a popular open source project is. A long time open sorceror himself (he kicked off Selenium, one of the early inversion of control frameworks, and a host of other initiatives), he likely assumed everyone suffered from the same desire to get off work every night to code and blog and manage a community like he does. Nonetheless, Paul has been both an incredibly helpful promoter of mountebank and an incredibly helpful mentor, even if I don’t always do a good job of listening to him. Of course, none of this would have been possible without the support of that first team, named SilverHawks after some cartoon that, despite being age appropriate for me, I never watched. I owe my thanks to Shyam Chary, Bear Claw, Gonzo, Andrew Hadley, Sarah Hutchins, Nagesh Kumar, Stan Guillory, and many others. The mountebank community has grown from those humble beginnings, and I owe a debt of gratitude to all the many folks who had dedicated their free time to improving the product. I was in Oklahoma City when Manning called to suggest writing a book. It was, like, really hard. Elesha Hyde, my development editor was amazing, even when I’d go silent for weeks at a time because work and life and kids ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank didn’t wait. I wrote this book in Oklahoma, Dallas, Toronto, Vancouver, San Francisco, San Antonio, Houston, Austin, Sao Paolo, and in Playa del Carmen. That’s right, I wrote parts of this book while drinking mojitos on the beach (and chapter 4 is better off for it). Which brings me to Mona. You let me write on weekends and on vacations. You let me write at family events and you let me write when your damn Patriots were playing in another damn Super Bowl (or whatever they call that last game, I don’t follow baseball that much anymore). You let me write at the spa and at the pool while you kept our kids from drowning. Thank you. ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/testing-microservices-with-mountebank about this book I wrote Testing Microservices with Mountebank to show how service virtualization helps you test microservices, and how mountebank is a powerful service virtualization tool. That necessarily requires building a deep familiarity with mountebank — the middle section of this book is dedicated to the subject — but many of the lessons apply with any service virtualization tool.