# Infosys Whitepaper 
Title: An Insight into Microservices Testing Strategies 
Author: Infosys Limited 
Format: PDF 1.7 

---

  Page: 1 / 8  

---

 WHITE PAPER AN INSIGHT INTO MICROSERVICES  TESTING STRATEGIES Arvind Sundar, Technical Test Lead Abstract The ever-changing business needs of the industry necessitate  that technologies adopt and align themselves to meet demands  and, in the process of doing so, give rise to newer techniques  and fundamental methods of architecture in software design. In  the context of software design, the evolution of “microservices”  is the result of such an activity and its impact percolates down  to the teams working on building and testing software in the  newer schemes of architecture. This white paper illustrates the  challenges that the testing world has to deal with and the effective  strategies that can be envisaged to overcome them while testing  for applications designed with a microservices architecture.  The paper can serve as a guide to anyone who wants an insight  into microservices and would like to know more about testing  methodologies that can be developed and successfully applied  while working within such a landscape.<|endoftext|>

---

  Page: 2 / 8  

---

 Microservices attempt to streamline the  software architecture of an application  by breaking it down into smaller units  surrounding the business needs of  the application. The benefits that are  expected out of doing so include creating  systems that are more resilient, easily  scalable, flexible, and can be quickly and  independently developed by individual  sets of smaller teams.<|endoftext|>Formulating an effective testing strategy  for such a system is a daunting task. A  combination of testing methods along  with tools and frameworks that can  provide support at every layer of testing is  key; as is a good knowledge of how to go  about testing at each stage of the test life  cycle. More often than not, the traditional  methods of testing have proven to be  ineffective in an agile world where changes  are dynamic. The inclusion of independent  micro-units that have to be thoroughly  tested before their integration into the  larger application only increases the  complexity in testing. The risk of failure and  the cost of correction, post the integration  of the services, is immense. Hence, there is  a compelling need to have a successful test  strategy in place for testing applications  designed with such an architecture.<|endoftext|>Introduction External Document © 2018 Infosys Limited 

---

  Page: 3 / 8  

---

 The definition of what qualifies as a  microservice is quite varied and debatable  with some SOA (service-oriented  architecture) purists arguing that the  principles of microservices are the same  as that of SOA and hence, fundamentally,  they are one and the same. However,  there are others who disagree and view  microservices as being a new addition to  software architectural styles, although  there are similarities with SOA in the  concepts of design. Thus, a simpler and  easier approach to understand what  microservices architecture is about, would  be to understand its key features: • Self-contained and componentized  • Decentralized data management • Resilient to failures • Built around a single business need • Reasonably small (micro) The points above are not essentially the  must-haves for a service to be called a  microservice, but rather are ‘good-to-have.’  The list is not a closed one either, as it  can also include other features that are  common among implementations of a  microservices architecture. However, the  points provide a perspective of what can  be termed as a microservice. Now that we  know what defines a microservice, let us  look at the challenges it poses to testers.<|endoftext|>The distributed and independent nature  of microservices development poses  a plethora of challenges to the testing  team. Since microservices are typically  developed by small teams working on  multiple technologies and frameworks, and  are integrated over light-weight protocols  (usually ReST over HTTPs, though this is  not mandatory), the testing teams would  be inclined to use the Web API testing  tools that are built around SOA testing.  This, however, could prove to be a costly  mistake as the timely availability of all  services for testing is not guaranteed, given  that they are developed by different teams.  Furthermore, the individual services are  expected to be independent of each other  although they are interconnected with  one another. In such an environment, a  key factor in defining a good test strategy  would be to understand the right amount  of testing required at each point in the test  life cycle.<|endoftext|>Additionally, if these services integrate  with another service or API that is exposed  externally or is built to be exposed to the  outside world, as a service to consumers,  then a simple API testing tool would prove  to be ineffective. With microservices, unlike  SOA, there is no need to have a service  level aggregator like ESB (enterprise  service bus) and data storage is expected  to be managed by the individual unit.  This complicates the extraction of logs  during testing and data verification, which  is extremely important in ensuring there  are no surprises during integration. The  availability of a dedicated test environment  is also not guaranteed as the development  would be agile and not integrated.<|endoftext|>Microservices architecture Challenges in testing microservices External Document © 2018 Infosys Limited 

---

  Page: 4 / 8  

---

 In order to overcome the challenges  outlined above, it is imperative that the test  manager or lead in charge of defining the  test strategy appreciates the importance  of Mike Cohn’s Test Pyramidi and is able to  draw an inference of the amount of testing  required.  The pictorial view emphasizes the need to  have a bottom-up approach to testing. It  also draws attention to the number of tests  and in turn, the automation effort that  needs to be factored in at each stage. The  representation of the pyramid has been  slightly altered for the various phases in  microservice testing. These are: i. Unit testing   The scope of unit testing is internal to  the service and in terms of volume of  tests, they are the largest in number.  Unit tests should ideally be automated,  depending on the development  language and the framework used  within the service.<|endoftext|>ii. Contract testing   Contract testing is integral to  microservices testing and can be of  two types, as explained below. The  right method can be decided based on  the end purpose that the microservice  would cater to and how the interfaces  with the consumers would be defined.  a) Integration contract testing:   Testing is carried out using a test  double (mock or stub) that replicates  a service that is to be consumed.  The testing with the test double  is documented and this set needs  to be periodically verified with the  real service to ensure that there are  no changes to the service that is  exposed by the provider.  b) Consumer-driven contract testing:   In this case, consumers define the  way in which they would consume  the service via consumer contracts  that can be in a mutually agreed  schema and language. Here, the  provider of the service is entrusted  with copies of the individual  contracts from all the consumers.  The provider can then test the  service against these contracts to  ensure that there is no confusion in  the expectations, in case changes  are made to the service.<|endoftext|>iii. Integration testing   Integration testing is possible in case  there is an available test or staging  environment where the individual  microservices can be integrated before  they are deployed. Another type of  integration testing can be envisaged  if there is an interface to an externally  exposed service and the developer  of the service provides a testing or  sandbox version. The reliance on  integration tests for verification is  generally low in case a consumer- driven contract approach is followed.<|endoftext|>iv. End-to-end testing   It is usually advised that the top layer   of testing be a minimal set, since a  failure is not expected at this point.  Locating a point of failure from an  end-to-end testing of a microservices  architecture can be very difficult and  expensive to debug.<|endoftext|>Mike Cohn’s Testing Pyramid E2E UI Testing Scope of Testing Execution Time Number of Tests Integration  Testing Contrast Testing Unit Testing Approach to testing microservices and testing phases External Document © 2018 Infosys Limited 

---

  Page: 5 / 8  

---

 • For unit testing, it would be ideal to  use a framework like xUnit (NUnit or  JUnit). The change in data internal to  the application needs to be verified,  apart from checking the functional  logic. For example, if reserving an  item provides a reservation ID on  success in the response to a REST call,  the same needs to be verified within  the service for persistence during unit  testing.<|endoftext|>• The next phase of testing in  contract testing. In case there are  several dissimilar consumers of the 