Continue # Infosys Whitepaper 
 service within the application, it is  recommended to use a tool that can  enable consumer-driven contract  testing. Open source tools like Pact,  Pacto, or Janus can be used. This  has been discussed in further detail  in the last example and hence, in  the context of this example, we will  assume that there is only a single  consumer of the service. For such  a condition, a test stub or a mock  can be used for testing by way of  REST over HTTPS Item ID. date Reservation ID Application Mocked Service Unit Testing Scope Integration Testing Scope Select an Item Reserve an item Integration Contract Testing Scope integration contract testing. Data  being passed between the services  needs to be verified and validated  using tools like SOAPUI. For example,  an item number being passed  between the services that selects it to  the one that reserves it.  • E2E tests should ensure that  dependency between microservices  is tested at least in one flow, though  extensive testing is not necessary. For  example, an item being purchased  should trigger both the ‘select’ and  ‘reserve’ microservices.<|endoftext|>In order to get a clear understanding of how testing can be carried out in different scenarios, let us look at a few examples that can help  elucidate the context of testing and provide a deeper insight into the test strategies used in these cases.<|endoftext|>• Scenario 1:    Testing between microservices internal to an application or residing within the same application   This would be the most commonly encountered scenario, where there are small sets of teams working on redesigning an application by  breaking it down into microservices from a monolithic architecture.  In this example, we can consider an e-commerce application that has two services a) selecting an item and b) reserving an item, which  are modelled as individual services. We also assume there is a close interaction between these two services and the parameters are  defined using agreed schemas and standards.<|endoftext|>Testing scenarios and test strategy External Document © 2018 Infosys Limited 

---

  Page: 6 / 8  

---

 • Unit tests should ensure that the  service model is catering to the  requirements defined for interacting  with the external service, while  also ensuring that internal logic is  maintained. Since there is an external  dependency, there exists a need to  ensure that requirements are clearly  defined and hence, documenting  them remains key. TDD approach is  suggested where possible and any of  the popular frameworks discussed in  the previous example can be chosen   for this.<|endoftext|>• Contract testing can be used in this  case to test the expectations from  consumer microservices, that is, the  applications internal service, decoupling  it from the dependency on the external  web service to be available. In this  context, test doubles, created using  tools like Mockito or Mountebank,  can be used to define the PayPal API’s  implementation and tested. This is  essentially integration contract testing  and again needs to be verified with  a live instance of the external service  periodically, to ensure that there is no  change to the external service that has  been published and consumed by the  consumer.<|endoftext|>• Integration tests can be executed if  the third-party application developer  • Scenario 2:    Testing between internal microservices and a third-party service   Here, we look at a scenario where a service with an application consumes or interacts with an external API. In this example,  we have considered a retail application where paying for an item is modelled as a microservices and interacts with the  PayPal API that is exposed for authenticating the purchase.<|endoftext|>  Let us look at the testing strategy in each phase of the test cycle in this case: provides a sandbox (e.g. PayPal’s  Sandbox APIii ) for testing. Live testing  for integration is not recommended.  If there is no availability of a sandbox,  integration contract testing needs to be  exercised thoroughly for verification of  integration.<|endoftext|>• E2E tests should ensure that there  are no failures in other workflows  that might integrate with the internal  service. Also, a few monitoring tests can  be set up to ensure that there are no  surprises. In this example, selecting and  purchasing an item (including payment)  can be considered an E2E test that can  run at regular and pre-defined intervals  to spot any changes or breaks.<|endoftext|>PayPal (External) API PayPal Sandbox API Unit Testing Scope Application Pay for an Item Test Double Virtual Provider Firewall  Contract Testing Scope Integration Testing Scope REST over HTTPS External Document © 2018 Infosys Limited 

---

  Page: 7 / 8  

---

 • Unit tests should cover testing for  the various functions that the service  defines. Including a TDD development  can help here to ensure that the  requirements are clearly validated  during unit testing. Unit test should also  ensure that data persistence within the  service is taken care of and passed on  to other services that it might interact  with.<|endoftext|>• Contract testing – In this example,  consumers need to be set up by using  tools that help define contracts. Also,  the expectations from a consumer’s  perspective need to be understood.  The consumer should be well-defined  and in line with the expectations in the  live situation and contracts should be  collated and agreed upon.<|endoftext|>  Once the consumer contracts are  validated, a consumer-driven contract  approach to testing can be followed. It  is assumed that in this scenario, there  would be multiple consumers and  hence, individual consumer contracts  for each of them. For example, in the  above context, a local retailer and  an international retailer can have  • Scenario 3:    Testing for a microservice that is to be exposed to public domain   Consider an e-commerce application where retailers can check for availability of an item by invoking a Web API.<|endoftext|>different methods and parameters of  invocation. Both need to be tested  by setting up contracts accordingly.  It is also assumed that consumers  subscribe to the contract method of  notifying the provider on the way  they would consume the service and  the expectations they have from it via  consumer contracts.<|endoftext|>• E2E tests – minimal set of E2E tests  would be expected in this case, since  interactions with external third parties  are key here Unit Testing Scope Application   Consumer Driven Contract Testing Scope REST over HTTPS REST over HTTPS Customer Contract 1 Virtual Consumer 1 Customer Contract 2 Virtual Consumer 2 External Document © 2018 Infosys Limited 

---

  Page: 8 / 8  

---

 Improvements in software architecture has led to fundamental changes in the way applications are designed and tested. Teams  working on testing applications that are developed in the microservices architecture need to educate themselves on the behavior of  such services, as well as stay informed of the latest tools and strategies that can help deal with the challenges they could potentially  encounter. Furthermore, there should be a clear consensus on the test strategy and approach to testing. A consumer-driven contract  approach is suggested as it is a better way to mitigate risk when services are exposed to an assorted and disparate set of consumers and  as it further helps the provider in dealing with changes without impacting the consumer. Ensuring that the required amount of testing  is focused at the correct time, with the most suitable tools, would ensure that organizations are able to deal with testing in such an  environment and meet the demands of the customer.<|endoftext|>References :  ihttps://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid       iihttps://www.sandbox.paypal.com In conclusion © 2018 Infosys Limited, Bengaluru, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys  acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this  documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the  prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.  For more information, contact askus@infosys.com Infosys.com | NYSE: INFY Stay Connected   


***


  