Contract Testing with Pact: A Different Approach - PDF document

¡ ¡ AT28 ¡ Agile ¡and ¡Continuous ¡Testing ¡ Thursday, ¡November ¡7th, ¡2019 ¡4:45 ¡PM ¡ ¡ ¡ ¡ ¡ Contract ¡Testing ¡with ¡Pact: ¡A ¡Different ¡ Approach ¡ ¡ Presented ¡by: ¡ ¡ ¡ ¡ Mihail ¡Mikulaninec ¡ ¡ MOO ¡ ¡ Brought ¡to ¡you ¡by: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 888 -­‑-­‑-­‑ 268 -­‑-­‑-­‑ 8770 ¡ ·√·√ ¡904 -­‑-­‑-­‑ 278 -­‑-­‑-­‑ 0524 ¡-­‑ ¡info@techwell.com ¡ ¡ https://agiledevopseast.techwell.com/ ¡ ¡ ¡

¡ ¡ ¡ ¡ Mihail ¡Mikulaninec ¡ ¡ Mihail ¡Mikulaninec ¡is ¡a ¡physicist ¡that ¡evolved ¡from ¡a ¡developer ¡at ¡a ¡medical ¡ company ¡to ¡an ¡automation ¡QA ¡engineer. ¡He ¡has ¡worked ¡with ¡various ¡businesses ¡ (fintech, ¡medicine, ¡design, ¡printing) ¡and ¡tech ¡stacks ¡(C++, ¡C#, ¡Ruby, ¡Python, ¡React, ¡ Java). ¡Mihail ¡is ¡passionate ¡about ¡microservices ¡architecture ¡and ¡CI/CD ¡with ¡a ¡focus ¡ on ¡quality. ¡He ¡has ¡been ¡involved ¡in ¡the ¡decoupling ¡strategy ¡for ¡a ¡number ¡of ¡ companies ¡in ¡order ¡to ¡move ¡toward ¡a ¡microservices ¡world. ¡He ¡currently ¡serves ¡as ¡ the ¡senior ¡automation ¡QA ¡engineer ¡at ¡MOO, ¡in ¡London, ¡UK. ¡ ¡

10/29/19 ¡ CON ONTRACT T TESTING W G WITH P PACT ︎ A D DIFFERENT A APPROA OACH ︎ BY M MICHAEL M MIKULANINEC ︎ 1 ABOUT MICROSERVICES 2 1 ¡


 ︎ 10/29/19 ¡ MICROS OSERVICES A ARCHITECTURE ︎ The idea is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each microservice is a small application that has its own architecture consisting of business logic along with various adapters. ︎ 3 MICROS OSERVICES D DIAGR GRAM ︎ INVENTOR ORY C CON ONTAINER ︎ INVENTOR ORY ︎ DB ︎ DB SERVICE SE RVICE ︎ DATA A AGGR GGREGA GATOR OR C CON ONTAINER ︎ ACCOU OUNT C CON ONTAINER ︎ API S SERVER C CON ONTAINER ︎ ACCOU OUNT ︎ DB DB ︎ API S SERVER ︎ WOR ORLD ︎ DATA A AGGR GGREGA GATOR OR ︎ SE SERVICE RVICE ︎ SHIPPING C G CON ONTAINER ︎ SHIPPING ︎ DB DB ︎ SE SERVICE RVICE ︎ 4 2 ¡


 ︎ 
 ︎ 10/29/19 ¡ BENEFITS OF OF M MICROS OSERVICES A ARCHITECTURE ︎ It t tackle les t the p proble lem o of It r reduces b barrie ier o of Mic icroservic ice It e enable les e each s servic ice comple lexit ity b by adoptin ing n new Mic icroservic ice archit itecture e enable les to b be d develo loped decomposin ing a applic licatio ion technolo logie ies s sin ince t the archit itecture e enable les each m mic icroservic ice t to b be independently in ly ︎ each s servic ice ︎ in into a a s set o of m manageable le develo lopers a are f free t to deplo loyed in independently ly. ︎ servic ices ︎ choose ︎ choose whic ich a are m much f faster t to whatever t technolo logie ies by a a t team t that is is As a a r result lt, it it m makes develo lop, a and m much e easie ier make s sense f for t their ir focused o on t that s servic ice. ︎ contin inuous d deplo loyment to b be s scale led in independently ly. ︎ to u understand a and servic ice a and n not b bound t to possib ible le f for c comple lex main intain in. ︎ the c choic ices m made a at t the applic licatio ions. ︎ start o of t the p project. ︎ 5 DRAWBACKS OF OF M MICROS OSERVICES ARCHITECT ARCHIT ECTURE URE ︎ Microservices architecture is adding complexity to the project just by the fact that a microservices application is a distributed system. ︎ Microservices has the partitioned database architecture. ︎ Testing a microservices application is also much more complex than in case of monolithic web application. ︎ It is more difficult to implement changes that span multiple services. ︎ Deploying a microservices-based application is also more complex. ︎ 6 3 ¡

︎ ︎ 
 ︎ 
 
 10/29/19 ¡ ABOUT PACT 7 CON ONTRACT T TESTING ︎ CON ONSUMER ︎ WITH P PACT ︎ A client that wants to receive some data ︎ Pact is a contract testing tool. Contract testing is a way to ensure that services (such as an API provider and a client) can communicate with each other. Without contract testing, the only way to know that services can communicate is by using expensive and brittle integration tests. ︎ MICROS OSERVICE ︎ Contract testing is immediately applicable anywhere where you have two services that need to communicate - such as an API client and a web front-end. ︎ ARCHITECT ARCHIT ECTURE URE ︎ In general, a contract is between a consumer (for example, a client that wants to receive some data) and a provider (for example, an API on a server that provides the data the client needs). ︎ A service or server that provides the data ︎ PROV OVIDER ︎ 8 4 ¡

︎ 
 ︎ 
 ︎ 10/29/19 ¡ An EXPECTED R REQU QUEST - describing what the consumer is expected to send to the provider 
 A c contract b between a a c consumer and p provid ider is is c calle lled a a P PACT. Each p pact is is a a c colle llectio ion o of interactio in ions. E Each in interactio ion describ ibes: ︎ A MINIMA MINIMAL expected response - describing the parts of the response the consumer wants the provider to return. ︎ 9 CONSUMER TESTING Consumer Pact tests operate on each interaction to say “ assuming the provider returns the expected response for this request, does the consumer code correctly generate the request and handle the expected response? ” . ︎ 10 5 ¡

︎ 
 ︎ 10/29/19 ¡ DIAGR GRAM W WITH C CON ONSUMER T TESTING ︎ TEST RUNNER ︎ Check whether the result makes me happy ︎ Configure pact server for the API to be like Hit the service you work with and get me the result ︎ Pact Data Aggregator Container ︎ The consumer Controllers ︎ Services ︎ ”Data Aggregator ” Web Server ︎ Expects the provider “Inventory Service to be Inventory ︎ Pact Mock Server ︎ External ︎ ACCOUNT ︎ Request/ ︎ Pact Controllers ︎ Account ︎ The consumer SERVICE ︎ Response ︎ ”Data Aggregator ” Handler ︎ Expects the provider “Account Service to be Shipping ︎ Pact The consumer ”Data Aggregator ” Expects the provider PACT ︎ “Shipping Service to be BROKER ︎ 11 Mock service can be different from the real service Get availability Inventory Get Inventory Get Mock product product ID Service price Service Get product price 12 6 ¡

10/29/19 ¡ PACT B BROK OKER ︎ is an application for sharing for consumer driven contracts and verification results. It is optimised for use with "pacts" (contracts created by the Pact framework), but can be used for any type of contract that can be serialized to JSON. ︎ 2 ︎ 3 ︎ 4 ︎ 1 ︎ Tells lls y you w whic ich v versio ions Allo llows y you t to e ensure ︎ Solv lves t the p proble lem o of h how ︎ Provid ides A API d documentatio ion ︎ of y your a applic licatio ions c can backwards c compatib ibilit ility ︎ to s share c contracts a and ︎ of y your a applic licatio ions t that is is ︎ be d deplo loyed s safely ly between m mult ltip iple le c consumer ︎ verif ific icatio ion r result lts b between ︎ guaranteed t to b be u up-t -to d date ︎ together together ︎ and p provid ider v versio ions ︎ consumer a and p provid ider p projects ︎ Allo llows y you t to r rele lease ︎ Shows y you r real e l example les Automatic ically lly v versio ions ︎ Allo llows y you t to v vis isualis lise t the customer v valu lue q quic ickly ly ︎ of h how y your s servic ices your c contracts ︎ rela latio ionship ips b between y your in interact ︎ and c confid idently ly ︎ servic ices ︎ 13 14 7 ¡

︎ 10/29/19 ¡ 15 PROV OVIDER V VERIFICATION ON ︎ PACT BROKER ︎ Data Aggregator Container ︎ Controllers ︎ Services ︎ Web Server ︎ Inventory ︎ Pact The consumer ”API Server ” External ︎ Expects the provider “Data Aggregator” Request/ ︎ PACT PROVIDER ︎ to be Controllers ︎ Account ︎ Response ︎ VERIFIER ︎ Handler ︎ Shipping ︎ 16 8 ¡

10/29/19 ¡ ABOUT SPECIAL WAY OF IMPLEMENTATION 17 CON ONVENTION ONAL I IMPLEMENTATION ON ︎ Consumer Tests import atexit import unittest from pact import Consumer, Provider (pact .given('UserA exists and is not an administrator') pact = .upon_receiving('a request for UserA') Consumer('Consumer').has_pact_with(Provider('Provider' .with_request('get', '/users/UserA') )) .will_respond_with(200, body=expected)) pact.start_service() atexit.register(pact.stop_service) with pact: result = user('UserA') class GetUserInfoContract(unittest.TestCase): self.assertEqual(result, expected) def test_get_user(self): expected = { 'username': 'UserA', 'id': 123, 'groups': ['Editors'] } 18 9 ¡