Testing Java Microservices Using Arquillian, Hoverfly, AssertJ, JUnit, Selenium, and Mockito (Alex Soto Bueno Andy Gumbrecht Jason Porter) (Z-Library)

M A N N I N G Alex Soto Bueno Andy Gumbrecht Jason Porter Using Arquillian, Hoverfly, AssertJ, JUnit, Selenium, and Mockito

Testing Java Microservices USING ARQUILLIAN, HOVERFLY, ASSERTJ, JUNIT, SELENIUM, AND MOCKITO ALEX SOTO BUENO ANDY GUMBRECHT AND JASON PORTER M A N N I N G SHELTER ISLAND

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com ©2018 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. Manning Publications Co. Development editor: Cynthia Kane 20 Baldwin Road Technical development editor: Adam Scheller PO Box 761 Project editor: Tiffany Taylor Shelter Island, NY 11964 Copyeditor: Tiffany Taylor Proofreader: Katie Tennant Technical proofreader: Joshua White Typesetter: Gordan Salinovic Cover designer: Marija Tudor ISBN 9781617292897 Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – DP – 23 22 21 20 19 18

To my parents: thanks for the ZX Spectrum. —A. S. To my children, Antony and Toriann. They get me, but they’ll never get this book! —A. G. To the amazing community of software engineers: together we do amazing things! And to my family and especially my wife, Tessie: thanks for being with me on this crazy journey of life. —J. P.

v contents preface xi acknowledgments xiii about this book xv about the authors xviii about the cover xx 1 An introduction to microservices 1 1.1 What are microservices, and why use them? 3 Why use microservices? 3 ■ What are microservices? 4 Continuous integration, deployment, and Docker 6 1.2 Microservice networks and features 6 Microservice networks 6 ■ Microservice features 7 1.3 Microservice architecture 8 Resource component 9 ■ Business-domain component 9 Remote resources component 9 ■ Persistence component 10 1.4 Microservice unit testing 10 Solitary unit tests 11 ■ Sociable unit tests 11 2 Application under test 13 2.1 Getting started 14

CONTENTSvi 2.2 Prerequisites 15 Java Development Kit 15 ■ Build tools 15 ■ Environment variables 16 ■ Integrated development environment (IDE) 16 2.3 Architecture 17 The game service 18 ■ The comments service 21 ■ The video service 23 ■ The aggregator service 25 ■ Overall architecture 26 2.4 Application design patterns 27 Anatomy 27 ■ ECB pattern 36 ■ Miscellaneous patterns 38 2.5 Design decisions 40 3 Unit-testing microservices 41 3.1 Unit testing techniques 41 Sociable unit tests 42 ■ Test doubles 43 ■ Solitary unit tests 45 ■ Unit testing in microservices 46 3.2 Tools 47 JUnit 48 ■ AssertJ 48 ■ Mockito 49 ■ Build-script modifications 50 3.3 Writing unit tests for the Gamer app 51 YouTubeVideoLinkCreator test 51 ■ YouTubeLink test 52 Games test 54 ■ GamesService test 56 ■ GamesResource test 58 4 Component-testing microservices 64 4.1 The Arquillian test framework 65 4.2 Introducing the @RunWith(Arquillian.class) annotation 68 4.3 The ShrinkWrap utility class 70 Building an archive with ShrinkWrap 71 ■ Adding content to the ShrinkWrap archive 71 ■ Adding resources 73 ■ Adding libraries and dependencies 74 ■ Adding complex dependencies with the Maven resolver 75 ■ Adding a service implementation 76 4.4 Write once and reuse your code 77 4.5 Build-script modifications 78 Defining Maven dependencies 79 ■ Defining Gradle dependencies 80 4.6 Overriding the default Arquillian configuration 81 The container definition 82 ■ Specifying container properties 83 4.7 Using Arquillian REST extensions 83 The Arquillian REST client extension 84 ■ The Warp REST extension 85

CONTENTS vii 4.8 Testing Spring applications using Arquillian 87 The Arquillian Spring Framework extension 87 ■ Testing Spring Boot applications 89 4.9 More-complex Arquillian test examples 91 Testing the remote component 91 ■ Testing the resource component 94 ■ Testing the domain component 96 ■ Testing the persistence component 96 5 Integration-testing microservices 100 5.1 Integration testing in the microservices architecture 101 Gateway component layer 102 ■ Data mappers and repositories 103 5.2 Persistence testing with the Arquillian Persistence Extension 103 Declarative approach 106 ■ Programmatic approach 108 Persistence testing with NoSQLUnit 112 ■ Persistence testing with Arquillian multideployment 116 ■ Persistence testing with Arquillian sequence 117 ■ Build-script modifications 117 5.3 Writing integration tests for the Gamer application 118 Testing the Comments class 119 ■ Testing the CommentsGateway class 122 6 Contract tests 128 6.1 Understanding contracts 128 Contracts and monolithic applications 129 ■ Contracts and microservice applications 130 ■ Verifying with integration tests 135 ■ What are contract tests? 135 ■ Who owns the contracts? 136 6.2 Tools 138 Pact 139 ■ Pact in JVM languages 140 ■ Integrating Pact JVM into the Arquillian ecosystem with Algeron 149 6.3 Build-script modifications 155 Using Pact JVM for contract testing 156 ■ Using Arquillian Algeron for contract testing 156 6.4 Writing consumer-driven contracts for the Gamer application 157 Consumer side of the comments service 157 ■ Provider side of the comments service 160 6.5 Contract type summary 163

CONTENTSviii 7 End-to-end testing 164 7.1 End-to-end tests in the overall testing picture 165 7.2 End-to-end testing techniques 165 Vertical tests 166 ■ Horizontal tests 166 7.3 Introduction to end-to-end testing tools 167 Arquillian Cube 167 ■ Arquillian Drone 167 ■ Arquillian Graphene 2 168 ■ JMeter 168 ■ Cukes in Space 168 7.4 Example end-to-end test 168 Building the microservices 169 ■ Adding the build dependencies and configuration 169 ■ Adding @Deployment and @TargetsContainer to the test 176 ■ Cross-origin resource sharing 177 ■ Coping with a mixed environment using @ClassRule 178 ■ Operating on the deployments with @OperateOnDeployment 183 ■ Introducing @Drone, page objects, @Location, and the WebDriver 184 ■ Working with page objects in a test 186 ■ Running the test 187 8 Docker and testing 190 8.1 Tools in the Docker ecosystem 191 Docker 191 ■ Docker Machine 193 ■ Docker Compose 194 8.2 Arquillian Cube 196 Setting up Arquillian Cube 197 ■ Writing container tests 199 Writing integration tests 201 ■ Writing end-to-end tests 205 8.3 Rest API 208 8.4 Arquillian Drone and Graphene 209 Integrating Arquillian Cube and Arquillian Drone 209 Integrating Arquillian Cube and Arquillian Graphene 212 8.5 Parallelizing tests 214 8.6 Arquillian Cube and Algeron 215 8.7 Using the container-objects pattern 216 Using a flexible container-object DSL 221 8.8 Deployment tests and Kubernetes 223 8.9 Build-script modifications 228 Arquillian Cube Docker 228 ■ Arquillian Cube Docker JUnit rule 229 ■ Arquillian Cube Kubernetes 229 ■ Arquillian Cube OpenShift 229 8.10 Testing the Dockerfile for the video service 230

CONTENTS ix 9 Service virtualization 233 9.1 What is service virtualization? 234 Why use service virtualization? 234 ■ When to use service virtualization 235 9.2 Mimicking service responses with Hoverfly 236 Hoverfly modes 236 ■ JUnit Hoverfly 238 ■ Configuring Hoverfly 239 9.3 Build-script modifications 240 9.4 Using service virtualization for the Gamer application 240 10 Continuous delivery in microservices 244 10.1 What is continuous delivery? 245 10.2 Continuous delivery and the microservices architecture 246 10.3 Orchestrating continuous delivery 248 Working with Jenkins 249 ■ The Jenkins pipeline 249 Deploying with certainty 252 10.4 Jenkins 254 Defining a pipeline 257 ■ Example of a Jenkins pipeline 259 appendix Masking multiple containers with Arquillian Chameleon 263 index 265

xi preface In the early days of programming, there were no frameworks. Tests consisted of ad hoc snippets of code that were put in place to ensure that important software features did roughly what they were supposed to. Storage space was very limited and precious at the time. Eventually, unit testing progressed from being a buzzword to being the de facto means for thoroughly testing software. Space concerns diminished to the point that they were a lame excuse for not writing test code. Today, it’s fair to say that all develop- ers learn and employ the unit-testing methodology early on, and it has become funda- mental to successful software development. Today’s enterprise applications require far more than just simple unit tests to maintain their integrity. Customers have become more demanding, and acceptance criteria are generally much higher. Multiple testing strategies must be applied throughout the development process if we’re to successfully meet this call. This book was written not only to address many of today’s current enterprise test- ing needs but also to add significant value by helping you decide how to approach the future testing requirements and challenges posed by the introduction of microser- vices into your architecture. It has taken us a long time to write this book: it has gone from being a small, single- chapter booklet on using a specific framework, to a 10-chapter, feature-packed epic that presents multiple testing strategies and options for you to choose from. We have learned much along the way, as this technology continually evolves. To provide as many options as possible, we’ve tried to focus more on strategies, methodology, and

PREFACExii solutions rather than on super-clean code and a stunning, yet ultimately unusable, application. If we can help you walk away with some good ideas for how to test your own applications, then we’ve achieved our goal. We hope you enjoy our candid style of writing, and we’d like to thank you for tak- ing the time to read this book.

xiii acknowledgments This book has had input from three independent developers, and we would first like to thank each other for all the hard work and feedback. Well done, and a pat on the back to each other! A huge thank you goes out to absolutely everyone involved in the Arquillian proj- ect, especially Aslak Knutsen, Dan Allen, Bartosz Majsak, and Matous Jobanek. Once you reach the end of the book, we’re sure you’ll understand how much effort has been put into this truly amazing project and how it will aid you in testing software. The Open Source Software (OSS) community provides many extremely useful tools that enable everyone to test efficiently. Much of the work done on these projects is performed through the tireless and often thankless work contributed by dedicated developers during their free time. We thank you wholeheartedly for your valued efforts. We would like to encourage you, the reader, to also thank these incredible people at every opportunity. A big thank you to Daniel Bryant and Marcin Grzejszczak for their time discussing contract testing. Cynthia Kane and Tiffany Taylor, our editors, were invaluable in pushing us for- ward when our motivation lagged. Writing a book in your spare time is challenging, to say the least. Thank you, Cynthia and Tiffany, for putting up with us. We also thank everyone else at Manning who made this book possible: publisher Marjan Bace and the editorial and production teams. Joshua White provided extensive proof-testing on the technical side: thanks to him for ironing out the glitches. He was our test tester!

ACKNOWLEDGMENTSxiv To everyone involved in providing feedback, a thank-you for taking the time to read and reread the book in order to help us produce the final material. These include our technical peer reviewers, led by Aleksandar Dragosavljević, Alex Jacinto, Anshuman Purohit, Boris Vasile, Conor Redmond, Eddú Meléndez Gonzales, Ethan A. Rivett, Fabrizio Cucci, Gualtiero Testa, Henrik Løvborg, Jan Paul Buchwald, Jona- than Thoms, José Díaz, Kiran Anantha, Leo van den Berg, Mari Machado, Nilesh Thali, Piotr Gliźniewicz, Robert Walsh, Yagiz Erkan, and Zorodzayi Mukuya. Last but certainly not least, we thank our wives and families for putting up with the long weekends, late hours, frustrations, and ups and downs of writing a book. We couldn’t have done it without their support!

xv about this book It’s apparent to every developer today that testing applications is a basic requirement of software development. This wasn’t always the case, and testing frameworks have come a long way since the early days. This book isn’t about the theory of why we test, because there’s plenty of information on that subject out there already. It was more important for us to figure out how to test, and how to convey that information to oth- ers. This book is very much focused on that approach, and the included application code provides a hands-on example from the start. A lot of information is of course available in the cloud, but more often than not, we find that when we actually have time to read, we’re not connected to the cloud (or choose not to be connected to it). It’s also nice to have a readily available resource that pulls all the useful information into one place—and we hope this book will serve as that type of resource for you. Testing is a general term, but testing is composed of a patchwork of technologies that you need to combine in order to gain the most benefit. We’ve collected a wide range of popular topics and components, and presented them in a way we feel makes the most sense for readers. Who should read this book We’d love to say “everyone,” but this isn’t much of a story book. Our target audience members are Java developers of Enterprise Edition (Java EE and Spring) applications. If that’s you, then this book will show you how to take unit testing to the next level.

ABOUT THIS BOOKxvi If you aren’t specifically a Java developer, this book may still be of interest to you. Much of the information provided is relevant and transferable to any programming language. As the title suggests, we’re targeting the popular transition to a microservice-based architecture. But we also provide a lot of information related to more general EE test- ing, so don’t be concerned that we’ve left things out—we just cover microservices in more depth. Roadmap This book has 10 chapters. Here’s a quick guide to what we cover: ■ Chapter 1 offers an introduction to and explanation of our preferred microser- vice terminology. ■ Chapter 2 presents our prerequisite expectations for reading this book and building the code, to save you time in the long run. ■ Chapter 3 will brush you up on common unit-testing techniques, methodolo- gies, and best practices. ■ Chapter 4 takes a deep dive into the Arquillian testing framework. ■ Chapter 5 explains how to create integration tests for dependent microservices. ■ Chapter 6 discusses consumer-driven and contract testing. ■ Chapter 7 explores ad hoc, end-to-end testing techniques and tools. ■ Chapter 8 covers creating reproducible testing environments with Docker. ■ Chapter 9 explores service-virtualization concepts and implementations. ■ Chapter 10 discusses continuous delivery and the Jenkins build pipeline. The order of the chapters was chosen to introduce the fundamental topics in a natu- ral progression. Each chapter builds on the next, but the book can also be read in your own order of interest. The programming language used in the book is Java, but the principles discussed can be applied to any language and framework. Code conventions and downloads This book contains many examples of source code both in numbered listings and inline with normal text. In both cases, source code is formatted in a fixed-width font like this to separate it from ordinary text. In many cases, the original source code has been reformatted; we’ve added line breaks and reworked indentation to accommodate the available page space in the book. In some cases, even this wasn't enough, and listings include line-continuation markers (➥). Additionally, comments in the source code have often been removed from the listings when the code is described in the text. Code annotations accompany many of the listings, highlighting important concepts. The source code for the book’s examples is available at www.manning.com/books/ testing-java-microservices.

ABOUT THIS BOOK xvii Book forum Purchase of Testing Java Microservices includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum, go to https://forums.manning.com/forums/testing-java-microservices. You can also learn more about Manning’s forums and the rules of conduct at https:// forums.manning.com/forums/about. Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place. It isn’t a commitment to any specific amount of participation on the part of the authors, whose contribution to the forum remains voluntary (and unpaid). We sug- gest you try asking them some challenging questions lest their interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

xviii about the authors ALEX SOTO is a Java Champion and software engineer working at Red Hat on develop- ing new tools to make better testing experiences. He enjoys the Java world, as well as software automation, and believes in the open source software model. Alex is the cre- ator of the NoSQLUnit project, a member of the JSR374 (Java API for JSON Process- ing) Expert Group, and an international speaker. Alex began programming with ZX Spectrum (in the good old days, using the POKE command) and had several different computers, such as an 80286. (He’s grateful to his parents, Mili and Ramon, for buying them.) After graduating as a computer engi- neer from La Salle Universitat Ramon Llull, he started his professional career in Aven- tia, developing a platform for generating and validating electronic signatures. Then he moved to Grifols to develop diagnostic medical devices; strict testing was an important part of the lifecycle of the software. Later, he worked for Everis, in the banking sector; Scytl, developing electronic voting systems; and CloudBees. Alex likes to spend his free time with his wife Jessica and his two daughters, Ada and Alexandra (ninetes dels meus ulls). ANDY GUMBRECHT is a senior software engineer at Tomitribe. He’s been interested in anything “computer” since around the age of 12, when he was fortunate to get his hands on a Sinclair ZX81 with a whopping 1 KB of memory. Many of the early exam- ples available were long lists of binary that needed to be typed in by hand. Sometimes that worked out, but Andy soon employed his brother John as his QA tester to ensure he’d gotten it right. That was when he first learned the value of testing code.

ABOUT THE AUTHORS xix Dabbling in machine code and BASIC continued to improve Andy’s skills at opti- mizing code. Later, and after a short spell as a Royal Engineer on operations in the British army, he returned to college in Germany to gain some paper qualifications. He interned at PROVOX Sytemplanung GmbH and stayed for many years, working on government software. Andy started to work on open source software around 2007 and has been involved in the Apache OpenEJB/Apache TomEE Application Server project since 2009, where he’s now a member of the Project Management Committee. JASON PORTER has been crafting software since he was 12. A couple of years before that, he discovered the amazing world of computers and programming on an old 80286 while looking through games written in BASIC. His interest in programming led him to Java and then C/C++. He became involved in web development in the early days, with Netscape Navigator and Internet Explorer. Fighting with things like DHTML and layers occupied his time. At the venerable age of 15, Jason got a job with a local web development company and spent time coding websites and writing CGI scripts in Perl. (He tries to forget those days, though.) Since that time, he’s worked in various indus- tries, coding in Java, PHP, Ruby, C#, and JavaScript. He primarily considers himself a backend developer, but the entire coding landscape is his playground. At Red Hat, Jason has worked on various frameworks, websites, and integrations. He’s spoken in the United States and internationally and is tickled every time he can help someone better understand a programming concept or new technology. Jason lives in Utah with his lovely wife and five children, whom he can’t program as easily as a computer.