Tweet
Tweet

Slide 1

Slide 1 text

@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Microservices Architecture Series Building Cloud Native Apps Testing Strategies Behavior Driven Design JUnit 5, TestNG, Spring Spock Cucumber, Selenium, Mockito, WireMock, Pact Dec 12th, 2024, | Bengaluru Agile Testing & Test Automation Day

Slide 2

Slide 2 text

@arafkarsh arafkarsh 2 My Primary Area of work Cloud-Native Architecture DDD, Event-Driven, Microservices, BDD, Containers, Kubernetes, Service Mesh, Testing, Data Mesh 1 Blockchain HyperLedger Ethereum CBDC / Tokens / NFT 2 App Security OWASP, Secure SDLC DevSecOps Zero Trust 3 Generative AI LLM, RAG GPT 4o, Gemini, Llama3, Claude 3, PalM2, Gemma, Phi3, Falcon 2, Mistral 4

Slide 3

Slide 3 text

@arafkarsh arafkarsh Github Codebase 3 Source: https://github.com/arafkarsh/ms-quickstart Springboot Examples 1. Kafka 2. Kafka Connect 3. Kafka Stream 4. OWASP Top Vulnerabilities & Fixes 5. Kubernetes 6. Test Automation 7. WebFlux Reactive Programming 8. Gen AI Examples github.com

Slide 4

Slide 4 text

@arafkarsh arafkarsh 4 Source: https://github.com/arafkarsh/ms-test-quickstart o SpringBoot 3.3.4 o Jakarta EE 10 o Java 23

Slide 5

Slide 5 text

@arafkarsh arafkarsh 5 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

Slide 6

Slide 6 text

@arafkarsh arafkarsh 6 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

Slide 7

Slide 7 text

@arafkarsh arafkarsh 0 Setting up the Context o Modernization (Building Cloud Native Apps) o SpecOps Workflow o Product Discovery o Shift Left – Operational Concerns o Case Studies – Health Care / eCommerce 7

Slide 8

Slide 8 text

@arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 8 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

Slide 9

Slide 9 text

@arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 9 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

Slide 10

Slide 10 text

@arafkarsh arafkarsh 10

Slide 11

Slide 11 text

@arafkarsh arafkarsh 11

Slide 12

Slide 12 text

@arafkarsh arafkarsh 12

Slide 13

Slide 13 text

@arafkarsh arafkarsh 13 Source: https://cloud.google.com/resources/devops/state-of-devops DORA – DevOps Research & Assessment

Slide 14

Slide 14 text

@arafkarsh arafkarsh 14 Our Goal Source: https://cloud.google.com/resources/devops/state-of-devops

Slide 15

Slide 15 text

@arafkarsh arafkarsh How to Transform into an Elite Team o Understanding What DevOps means o DevOps Best Practices 15

Slide 16

Slide 16 text

@arafkarsh arafkarsh Management Pipeline Automation Architecture SpecOps Workflow - SDLC 16 Green Field Brown Field Domain Driven Design Event Sourcing / CQRS Migration Patterns Strangler Fig, CDC… Build Design Develop Test Stage Ops Cloud • Fault Tolerance • Reliability • Scalability • Traffic Routing • Security • Policies • Observability • Unit Testing • Component • Integration • Contract • Package Repositories • Mvn, npm, docker hub • Infrastructure • Containers • Orchestration • Serverless • Traffic Routing • Security (mTLS, JWT) • Policies (Network / Security) • Observability Infra Code • Feature Code • Configs Source Code Specs

Slide 17

Slide 17 text

@arafkarsh arafkarsh Cloud-Native Architecture 17 Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Event Based / Event Sourcing & CQRS Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics

Slide 18

Slide 18 text

@arafkarsh arafkarsh Specs, Architecture, Design, Packaging 18 EPIC Bounded Context Micro Service Pod User Stories MVP Domain Driven Design Service Architecture Container Orchestration Design Thinking Lean Startup Agile (Kanban) CI/CD/CD, DevSecOps Specs Deploy Design / Develop Code Process Test Automation Code, Infra Code, Continuous Integration, Continuous Delivery, Continuous Deployment DFD L1 Data Flow Diagrams

Slide 19

Slide 19 text

@arafkarsh arafkarsh Production Environment Continuous Monitoring Fully Automated Continuous Deployment Shift Left – Operational Concerns 19 • Operations Concerns move earlier in software delivery life cycle, towards development. • The Goal is to enable Developers and QC Team to Develop and Test the software that behave like Production System in fully automated way. Development Environment Build Build Build Test Environment Continuous Integration Unit Testing Component Testing Contract Testing Integration Testing Continuous Testing Shift Left moves operations earlier in development cycle. Stage Environment Acceptance Testing Pull Request / Merge Continuous Delivery GitOps – CD/CD

Slide 20

Slide 20 text

@arafkarsh arafkarsh ShopEasy – eCommerce Portal 20 Theme Epic User Story Sprint ShopEasy – eCommerce Application 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating

Slide 21

Slide 21 text

@arafkarsh arafkarsh Behavior Driven Development 21 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned.

Slide 22

Slide 22 text

@arafkarsh arafkarsh User Journey / Story Map & Release Cycles 22 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use UPI R2 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Minimum Viable Product Scrum Sprint Cycle Search by Price Image Gallery Update Qty Use UPI Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent!

Slide 23

Slide 23 text

@arafkarsh arafkarsh 23 Shopping Portal /Web Ui /Authentication /product /review Mesh – API GW Nodes Firewall Web Ui Pod Web Ui Pod Web App Service N2 N1 Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB Review Pod Review Pod Review Pod Review Service N4 N3 N1 Users Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Mongo DB Mongo DB Auth Pod Auth Pod Auth / Authorize Service N3 N5 MySQL DB Generates Token (JWT) Services will process requests only if the token is valid istiod Istio Control Plane K8s Load Balancer External Load Balancer Kubernetes Objects Istio Objects Istio Sidecar Envoy

Slide 24

Slide 24 text

@arafkarsh arafkarsh Microservices Testing Strategies 24 E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10% Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Architect

Slide 25

Slide 25 text

@arafkarsh arafkarsh Microservices Testing Strategy 25 Unit Testing A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected. Source: https://martinfowler.com/articles/microservice-testing/#agenda Component Testing A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components. Integration Testing An integration test verifies the communication paths and interactions between components to detect interface defects Integration Contract Testing An Integration Contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. End 2 End Testing An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end. Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog

Slide 26

Slide 26 text

@arafkarsh arafkarsh Other Testing Strategies or Anti Patterns 26 End 2 End Testing Integration Testing Unit Testing Inverted Pyramid / Ice Cream Cone Strategy Unit Testing Integration Testing End 2 End Testing Hour Glass Strategy 70% 20% 10% 45% 45% 10%

Slide 27

Slide 27 text

@arafkarsh arafkarsh Microservices Testing Scenarios / Tools 27 Testing Tools Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock Integration Contract Testing Scope Test Double Montebank Cart Component Testing Unit Testing Integration Testing Scope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing U

Slide 28

Slide 28 text

@arafkarsh arafkarsh Chaos Engineering – Load / Stress / Performance 28 Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Search for unused resources and disposes them. Compliance Monkey Finds instances that don’t adhere to best-practices and shuts them down. Latency Monkey Induces Artificial delays Security Monkey Is an extension of Compliance Monkey. Find security vulnerabilities and terminates offending instances. Source: https://github.com/Netflix/SimianArmy/wiki Source: http://principlesofchaos.org/

Slide 29

Slide 29 text

@arafkarsh arafkarsh 100s Microservices 1,000s Releases / Day 10,000s Virtual Machines 100K+ User actions / Second 81 M Customers Globally 1 B Time series Metrics 10 B Hours of video streaming every quarter Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM 10s OPs Engineers 0 NOC 0 Data Centers So what do NetFlix think about DevOps? No DevOps Don’t do lot of Process / Procedures Freedom for Developers & be Accountable Trust people you Hire No Controls / Silos / Walls / Fences Ownership – You Build it, You Run it. 29

Slide 30

Slide 30 text

@arafkarsh arafkarsh Testing Strategy Summary 30 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects.

Slide 31

Slide 31 text

@arafkarsh arafkarsh 31

Slide 32

Slide 32 text

@arafkarsh arafkarsh 32 This is the trailer for a new movie fully written by ChatGPT 4o. His first feature film VERFLIXT VERLIEBT (2004) won the Zurich Film Prize and was awarded at the Max Ophüls Film Festival. He was co-author of VITUS (2006), which was a box-office success and was shortlisted for an Oscar. His films DER SANDMANN (2011) and SCHWEIZER HELDEN (2014) won numerous awards, including the audience prize at the Locarno Film Festival. FLITZER (2017) was a commercial success and was sold in over 50 territories. BON SCHUUR TICINO is a brilliant Swiss cinema released in the autumn of 2023. The Last Screenwriter’s director, Peter Luisi, is a Zurich-born filmmaker, is a 6 - time nominee at the Swiss Film Awards, 3 times for screenwriting.

Slide 33

Slide 33 text

@arafkarsh arafkarsh AI Enriched Testing tools 33 1. Diffblue Cover o AI-Powered Unit Test Generation: Diffblue Cover automatically generates unit tests for Java applications. It analyzes your code and creates tests to maximize coverage and detect potential bugs. o Integration with Spring Boot: Diffblue Cover integrates well with Java Spring Boot applications, generating tests for your services, controllers, and repositories. o Enhanced Mocking: The generated tests can utilize frameworks like Mockito to create necessary mocks. 2. SmartBear TestComplete o AI-Driven Functional Testing: TestComplete uses AI for functional and UI testing, offering smart object recognition and self-healing capabilities. o API Testing and Mocking: While primarily focused on UI testing, it also supports API testing and can be integrated with existing mocking frameworks like WireMock. 3. Applitools o Visual AI Testing: Applitools Eyes uses visual AI to perform visual testing of applications. o Integration with Mocks: It can be integrated with Selenium and other Java testing frameworks, enhancing visual verification alongside functional tests that use Mockito or WireMock.

Slide 34

Slide 34 text

@arafkarsh arafkarsh Diffblue Cover o Autogenerate Unit Test cases with Mock Objects 34

Slide 35

Slide 35 text

@arafkarsh arafkarsh Setup 35 1. Open IntelliJ IDEA. 2. Navigate to the File menu → Settings (or Preferences on macOS). 3. In the settings window, select Plugins from the left- hand menu. 4. In the Marketplace tab, search for Diffblue Cover. 5. Click Install next to the Diffblue Cover plugin. 6. Restart IntelliJ IDEA to complete the installation. 2 3 4 5

Slide 36

Slide 36 text

@arafkarsh arafkarsh 36 Auto Generate Test Cases Order Controller

Slide 37

Slide 37 text

@arafkarsh arafkarsh 37 Auto Generate Test Cases Order Controller

Slide 38

Slide 38 text

@arafkarsh arafkarsh 38 Auto Generate Test Cases Order Controller

Slide 39

Slide 39 text

@arafkarsh arafkarsh 39 Order Repository Test Generation Process

Slide 40

Slide 40 text

@arafkarsh arafkarsh Testing Strategy Summary 40 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects.

Slide 41

Slide 41 text

@arafkarsh arafkarsh 41 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India: +91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

Slide 42

Slide 42 text

@arafkarsh arafkarsh 42 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh github.com

Slide 43

Slide 43 text

@arafkarsh arafkarsh In-Depth Walk Through o JUnit5, TestNG, Spring Spock o Mockito, Cucumber & Selenium o WireMock, Pact 43

Slide 44

Slide 44 text

@arafkarsh arafkarsh 44 Slides are color coded based on the topic colors. Testing Strategies Microservices 1 Platforms JUnit 5, TestNG, Spock 2 Behavior Driven Development Cucumber, Selenium Mockito, RestAssured 3 Integration / Contract Testing WireMock, Pact 4

Slide 45

Slide 45 text

@arafkarsh arafkarsh Agile Scrum (4-6 Weeks) Developer Journey Monolithic Domain Driven Design Event Sourcing and CQRS Waterfall Optional Design Patterns Continuous Integration (CI) 6/12 Months Enterprise Service Bus Relational Database [SQL] / NoSQL Development QA / QC Ops 45 Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Design Patterns Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh

Slide 46

Slide 46 text

@arafkarsh arafkarsh Product Discovery 46 Increasing level of Evidence of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K

Slide 47

Slide 47 text

@arafkarsh arafkarsh Cloud-Native Architecture 47 Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Event Based / Event Sourcing & CQRS Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics

Slide 48

Slide 48 text

@arafkarsh arafkarsh Specs, Architecture, Design, Packaging 48 EPIC Bounded Context Micro Service Pod User Stories MVP Domain Driven Design Service Architecture Container Orchestration Design Thinking Lean Startup Agile (Kanban) CI/CD/CD, DevSecOps Specs Deploy Design / Develop Code Process Test Automation Code, Infra Code, Continuous Integration, Continuous Delivery, Continuous Deployment DFD L1 Data Flow Diagrams

Slide 49

Slide 49 text

@arafkarsh arafkarsh Features of BDD 49 • Focus on Behavior of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development https://cucumber.io/ Free and Open-Source Framework for Java Stack. Free and Open Source BDD Framework for .Net Stack https://specflow.org/

Slide 50

Slide 50 text

@arafkarsh arafkarsh User Story 50 Role-Feature-Reason Matrix Story Card These three elements (WHO, WHAT, WHY) are the building blocks of User stories. Element Example Role WHO: As an e-Commerce Retailer Feature WHAT: I want to know who my Gold Customers are Reason WHY: So that I sell more Element Definition WHO: Establishes the user or users or another service. WHAT: Describes the Activity – Key Axis of the Story. What the user does in the story. WHY: This describes the purpose of the story. Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019 User stories are NOT 1. IEEE 830 Software Specs 2. Use Cases Use Cases are a combination of User Story and Acceptance Criteria 3. Scenarios

Slide 51

Slide 51 text

@arafkarsh arafkarsh Acceptance Criteria / Behavior Driven Development 51 Source: https://dannorth.net/introducing-bdd/ Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Acceptance Criteria The definition of Done – As per Scrum These three elements (GIVEN WHEN THEN) are the building blocks of Acceptance Criteria. Typical SDLC Life Cycle Analyst Specifies the Use Case Developer The developer builds software based on Specific Usage scenarios with respect to the Use Case. Tester Tester builds test cases based on Use Case Scenarios and finds issues. The Gaps identified in this process are filled up by linking the User Stories with Acceptance Criteria.

Slide 52

Slide 52 text

@arafkarsh arafkarsh Behavior Driven Development 52 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned.

Slide 53

Slide 53 text

@arafkarsh arafkarsh Example 1: Healthcare App 53 Theme / Initiative Epic User Story Sprint Healthcare / We Care 1. Patient 2. Healthcare Staff 3. Appointments 4. Diagnosis 5. Lab 6. Pharmacy 7. Auth 4. Diagnosis Release 1 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription Release 2 1. Prescribe for Lab Tests Stories 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription 4. Prescribe for Lab Tests

Slide 54

Slide 54 text

@arafkarsh arafkarsh User Journey with Story Map & Release Cycles 54 1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine 5. Lab Tests Health Staff Appointment Pharmacy Lab Diagnosis 2. Search & Select Doctor Patient User Journey Minimum Viable Product Upload Medical Docs Add Doctor / Nurse Cancel Appointment R2 Lab Tests View Medical History Duty Calendar R3 Reschedule Register Search Doctor Available Dates Book Appointment Medical History Check Verify Prescription Pack Medicines R1 Pre-Checkup Diagnosis & Prescription Appointment Upload Results Schedule Duty Time Make Payment Share Medical Docs R4 Appointment Calendar Make Payment View Appointments Email SMS

Slide 55

Slide 55 text

@arafkarsh arafkarsh Example 2: eCommerce Portal / Shop Easy 55 Theme / Initiative Epic User Story Sprint eCommerce / Shop Easy 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating

Slide 56

Slide 56 text

@arafkarsh arafkarsh User Journey with Story Map & Release Cycles 56 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Search by Brand Product Reviews Pay Debit Card R3 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Search by Model Search by Rating R4 Minimum Viable Product

Slide 57

Slide 57 text

@arafkarsh arafkarsh Epic – Customer 57 As a Consumer I want to register eCommerce Portal So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Registration BDD Acceptance Criteria – 1: Save User Given The fields First Name, Last Name, DOB Address, Email Address, Phone No. When The user enters values in the fields First Name, Last Name, DOB Address, Email Address, and Phone No. Then If the following fields contain values First Name, Last Name, Address, Email Address, and Phone No. AND Age is greater than 18, then Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When The email address is a valid email id. Then Generate the Password AND Send mail with the user email address as login id and the URL of the portal AND Send the Password to a separate email address. AND Store data on mail status as mail sent or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available. When The Mail status is equal to "Failed". Then Send the mail again AND store the attempt number.

Slide 58

Slide 58 text

@arafkarsh arafkarsh Epic – Search (Product) 58 As a Consumer I want to search for a product So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Global Search BDD Acceptance Criteria – 1 : Global Search Given The user logged into the portal, and the product search page was available. When The user enters the product name and clicks search Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records. BDD Acceptance Criteria – 2 : Global Search Given The Request is authenticated. When Input contains Product Name Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records.

Slide 59

Slide 59 text

@arafkarsh arafkarsh Epic – Order : Credit Card 59 As a Consumer I want to Process the Order So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user is on the Order Page with Items and selected Shipping Address. When The user Selects the Payment Option As a Credit Card AND Input the Credit Card Details in the following fields Card Name, Card No. Expiry Date (MM/YYYY), CVV Number. Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the info and proceeds with the payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated. When The input contains the user login id, order id, and payment details (card number only last four digits). Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the following info Card Name, Card Number (only last 4 digits), Expiry Date and proceeds with the payment. BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated. When The input contains Valid payment details. Then The Request with the valid Payment Details, the System calls the External Payment Service for Payment Processing and Returns the Result to the Calling System.

Slide 60

Slide 60 text

@arafkarsh arafkarsh Testing Strategy Summary 60 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects.

Slide 61

Slide 61 text

@arafkarsh arafkarsh Microservices Testing Strategies • Unit testing • Component testing • Integration Contract testing • Integration testing 61 1

Slide 62

Slide 62 text

@arafkarsh arafkarsh 62 Junit 5 5.10.2 Cucumber 7.18.0 Mockito 5.12.0 Selenium 4.12.0 WireMock 3.6.0 Pact 4.0.10 Source: https://github.com/arafkarsh/ms-test-quickstart Rest Assured 5.4.0 SpringBoot 3.3.4 TestNG 7.10.2 Spock 2.4

Slide 63

Slide 63 text

@arafkarsh arafkarsh 63 Source: https://github.com/arafkarsh/ms-test-quickstart

Slide 64

Slide 64 text

@arafkarsh arafkarsh Order Service API Calls 64 http://localhost:9080/swagger-ui.html Based on Open API v3

Slide 65

Slide 65 text

@arafkarsh arafkarsh JUnit 5 • JUnit 5 Testing • Annotations • Tags and Filtering • Meta Annotations • Basic Assertions in JUnit 5 • Testing Categories 65 2

Slide 66

Slide 66 text

@arafkarsh arafkarsh JUnit 5 – Unit Testing 66 Assert @BeforeAll @BeforeEach @Test @AfterEach @AfterAll System Under Test All the Test Cases Setup Check Verify Teardown Test Suites Teardown All Setup All

Slide 67

Slide 67 text

@arafkarsh arafkarsh JUnit 5 – Test Annotations 67 @Test @RepeatedTest @ParametrizedTest @NestedTest @ValueSource @EnumSource @MethodSource @CsvSource @CsvFileSource @ArgumentSource @DisplayName Give meaningful name for your tests @Tag Categorize and Filter your tests. @Order Execute your tests in a specific order. @Disabled Disables your test

Slide 68

Slide 68 text

@arafkarsh arafkarsh JUnit 5 – Tags and Filtering 68 Functional Non-Functional Performance Usability Security Accessibility Stress Load

Slide 69

Slide 69 text

@arafkarsh arafkarsh JUnit 5 – Meta Annotations 69 Non-Functional Performance Load

Slide 70

Slide 70 text

@arafkarsh arafkarsh Filtering in POM File using Sure Fire Plugin 1. Using Tags, you can filter specific tests to get executed in your build process. 2. For Ex. If you tags like All, Unit, Components, Contract, and Integration and you want to run only Component and Contract Testing and exclude Non- Functional Tests. Then Component, Contract Non-Functional

Slide 71

Slide 71 text

@arafkarsh arafkarsh Junit 5 – Parametrized Tests 71 Value Source Enum Source

Slide 72

Slide 72 text

@arafkarsh arafkarsh Basic Assertions in JUnit 5 72 Assertion Details fail Fails a test with a given message and or Exception assertTrue Validates that the supplied Condition is True assertFalse Validates that the supplied Condition is False assertNull Validates the the supplied Object is Null assertEquals Validates that 2 supplied Objects are equal assertArrayEquals Validates that 2 supplied Arrays are equals assertIterableEquals Validates that 2 supplied Iterable Objects are equal. assertLineMatch Validates that 2 lines of Strings are equal. assertNotEquals Validates that 2 supplied Objects are NOT Equal assertSame Validates that 2 Object are same – compared with == assertNotSame Validates that 2 Objects are not same – compared with !=

Slide 73

Slide 73 text

@arafkarsh arafkarsh Assertions in JUnit 5 73 Assertion Details assertAll Groups different Assertion at the same time assertThrows To verify that a given Exception is thrown from piece of code. assertTimeout Verifies the timeout of a given operation assertTimeoutPreemptively If the timeout exceeds then terminated. 3rd Party Assertions assertThat An object is matched with a Matcher to see if it meets the expectation.

Slide 74

Slide 74 text

@arafkarsh arafkarsh JUnit 4 >> JUnit 5 74 JUnit 4 JUnit 5 @BeforeClass Executed Before All @Test in the Current Class @BeforeAll @Before Executed Before each @Test @BeforeEach @After Executed After Each @Test @AfterEach @AfterClass Executed After All @Test in the Current Class @AfterAll @Category To Group the test cases @Tag

Slide 75

Slide 75 text

@arafkarsh arafkarsh JUnit 5 – Parametrized Tests 75 CSV Source CSV File Source

Slide 76

Slide 76 text

@arafkarsh arafkarsh JUnit 5 – Parametrized Tests 76 Method Source

Slide 77

Slide 77 text

@arafkarsh arafkarsh JUnit 5 – Parametrized Tests 77 Argument Source Argument Source Provider

Slide 78

Slide 78 text

@arafkarsh arafkarsh JUnit 5 – Nested Tests 78

Slide 79

Slide 79 text

@arafkarsh arafkarsh JUnit 5 – Repeated Tests 79

Slide 80

Slide 80 text

@arafkarsh arafkarsh 80 3 Component / Contract Testing o Behavior Driven Development o Mockito o SpringBoot Test o Rest Assured o Cucumber

Slide 81

Slide 81 text

@arafkarsh arafkarsh Features of BDD 81 • Focus on Behavior of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development https://cucumber.io/ Free and Open-Source Framework for Java Stack. Free and Open Source BDD Framework for .Net Stack https://specflow.org/

Slide 82

Slide 82 text

@arafkarsh arafkarsh Behavior Driven Development 82 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned.

Slide 83

Slide 83 text

@arafkarsh arafkarsh REST Assured o Concept o General Test Cases o Security Test Cases o Other Test Cases 83

Slide 84

Slide 84 text

@arafkarsh arafkarsh Features 84 1. DSL (Domain Specific Language): REST Assured provides a robust set of DSL keywords like given, when, then, post, get, etc., which are easy to understand and help write expressive tests. 2. Request and Response Specification: REST Assured allows you to set common properties that can be shared across multiple tests. For example, if all your API endpoints require standard headers, you can set them in a request specification and use them in all your tests. 3. Path, Query, and Form Parameters: REST Assured provides manageable methods to set path parameters, query parameters, and form parameters. 4. Headers and Cookies: You can easily set headers and cookies in your requests. 5. Authentication: REST Assured supports multiple types of authentication, like Basic, Digest, Form, OAuth, etc. 6. Content Parsing: REST Assured can automatically parse JSON and XML responses. This allows you to navigate the response body and perform validations efficiently. 7. Validations: REST Assured supports a variety of validations, including status codes, headers, cookies, and body.

Slide 85

Slide 85 text

@arafkarsh arafkarsh Embedded Springboot App 85 Embedded Server

Slide 86

Slide 86 text

@arafkarsh arafkarsh GET Request 86

Slide 87

Slide 87 text

@arafkarsh arafkarsh POST Request 87

Slide 88

Slide 88 text

@arafkarsh arafkarsh Put Request 88

Slide 89

Slide 89 text

@arafkarsh arafkarsh Delete Request 89

Slide 90

Slide 90 text

@arafkarsh arafkarsh Shared Specs 90

Slide 91

Slide 91 text

@arafkarsh arafkarsh Shared Specs 91 Shared Specs across multiple test cases.

Slide 92

Slide 92 text

@arafkarsh arafkarsh Security: Deny Page rendering in Frame 92

Slide 93

Slide 93 text

@arafkarsh arafkarsh XSS Protection 93

Slide 94

Slide 94 text

@arafkarsh arafkarsh Cucumber • Features • Steps 94

Slide 95

Slide 95 text

@arafkarsh arafkarsh BDD Specs 95 BDD Style Specs for Searching for a Product in Amazon

Slide 96

Slide 96 text

@arafkarsh arafkarsh Cucumber JUnit 4 Integration 96 Specs Definition Steps for Testing

Slide 97

Slide 97 text

@arafkarsh arafkarsh Step Definitions 97 Dependency Injection

Slide 98

Slide 98 text

@arafkarsh arafkarsh Specs for Payment Criteria 98

Slide 99

Slide 99 text

@arafkarsh arafkarsh Theme/Epic – Shopping Portal / Cart 99 As a Consumer I want to Add a Product to Cart So that I can buy the product Role-Feature-Reason Matrix User Story – 1 : Add to Cart BDD Acceptance Criteria – 1: Add to Cart Given The user logged into the portal and a Product is selected and Product details are available When The user then clicks Add to Cart Button Then The system will add the Item (Product) into the card and Updates Item counter in the Cart Icon AND Saves the Cart information in the DB AND if the save fails the system shows an Error “Unable to Add Product to the Cart”. BDD Acceptance Criteria – 2: Save Cart Given The Request is authenticated When The Input contains user login id, product id Then The system will add the Item (Product) into the Cart & Saves the Cart information in the DB AND if the save fails the system shows an Error “Unable to Add Product to the Cart”.

Slide 100

Slide 100 text

@arafkarsh arafkarsh Theme/Epic – Shopping Portal / Customer 100 As a Consumer I want to Select Shipping Address So that I can ship the items to that Address Role-Feature-Reason Matrix User Story – 3 : Select Address BDD Acceptance Criteria – 1 : Show Address Given The user in the Shopping Cart Page When User Clicks Proceed to Buy Button Then The System shows the Available Address for Shipping BDD Acceptance Criteria – 2 : Select Address Given The user in the Shopping Cart Page with Available Shipping Address When User Selects Address and Clicks Proceed to Buy Then The System save the Temp Order details from Items from Shopping and Selected Shipping Address AND this details are valid only for the user session. If the order is not placed Temp Order items will be put back in Cart DB BDD Acceptance Criteria – 3 : Save Temp Order Given The Request is authenticated When Input contains user login id, items, shipping address Then The System save the Temp Order details from Items from Shopping and Selected Shipping Address AND this details are valid only for the user session. If the order is not placed Temp Order items will be put back in Cart DB

Slide 101

Slide 101 text

@arafkarsh arafkarsh Theme/Epic – Shopping Portal / Order 101 As a Consumer I want to Process the Order So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user in the Order Cart Page with Items and selected Shipping Address When User Selects Payment Option As Credit Card AND Input the Credit Card Details in the following fields Card Name, Card No. Expiry Date, CVV Number Then The System Validates the Credit Card Number and the Expiry Date and Card Name & CVV Must NOT be Null IF Invalid Systems says invalid Payment details else Saves the info and proceed for payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated When Input contains user login id, order id, payment details (card number only last 4 digits) Then The System Validates the Credit Card Number and the Expiry Date and Card Name and CVV Must NOT be Null IF Invalid Systems returns invalid Payment details ELSE Saves the following info Card Name, Card Number (only last 4 digits), Expiry Date BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated When Input contains Valid payment details Then With the Valid Payment Details System calls External Payment Service for Payment Processing and Returns Result to Calling System

Slide 102

Slide 102 text

@arafkarsh arafkarsh As a Patient I want to get diagnosed by a Doctor So that I can be healthy again Role-Feature-Reason Matrix User Story – 1 : Patient Diagnosis BDD Acceptance Criteria – 1 : Show Patient Info Given The Patient John Doe Exists and has an Appointment with the doctor When The Doctor selects the Patient Info Then The System shows the Patient Info with following details Patient Name, Age, Gender, Contact No. and the Health info contains the following Pulse, Blood Pressure, Height and Weight BDD Acceptance Criteria – 2 : Add Diagnosis Given Patient Details are Available When Doctor Selects Add Diagnosis Then The system shows a text area for adding the diagnosis and the doctor can add multiple diagnosis. BDD Acceptance Criteria – 4 : Save Diagnosis Given The Request is authenticated When Input contains Patient Diagnosis Details Then With the Valid Patient Diagnosis Details and the system will save the data send the response back to the user. BDD Acceptance Criteria – 3 : Add Prescription Given Patient Details & Diagnosis are Available When Doctor Selects Add Prescription Then The system shows a text area for adding the prescription, and the frequency of usage in a day and for how many days, and the doctor can add multiple prescription. Theme/Epic – Hospital / Diagnosis 102

Slide 103

Slide 103 text

@arafkarsh arafkarsh Cucumber Junit 4 Integration 103 Specs Definition Steps for Testing

Slide 104

Slide 104 text

@arafkarsh arafkarsh Mockito Component / Mock / Contract Testing 104

Slide 105

Slide 105 text

@arafkarsh arafkarsh Mock Testing Tools Trends for the Last 20 Years 105

Slide 106

Slide 106 text

@arafkarsh arafkarsh Mockito Concepts 106 Verify 3. Verify Expectations and Results Verify Result 1. Set the expectations Expect When() Then Return() Use 2. Use the object being tested Test your Component

Slide 107

Slide 107 text

@arafkarsh arafkarsh Annotation – @Mock, @InjectMock 107 Create Mocks for 1. Repository 2. Payment Service Inject the Mocks into Order Service Scenario Create Mocks for the following 1. Repository Service 2. Payment Service Annotations • @Mock • @InjectMocks Test Cases 1. Given a Valid Order 2. Test for Payment Accepted 3. Test for Payment Declined

Slide 108

Slide 108 text

@arafkarsh arafkarsh Conditions – when().thenReturn() 108 Test Cases 1. Given a Valid Order 2. Test for Payment Accepted 3. Test for Payment Declined

Slide 109

Slide 109 text

@arafkarsh arafkarsh Annotation - @Spy 109 Spy works on the Actual Implementation Inject the Mocks into Order Service Scenario Create Mocks for the following 1. Packaging Service 2. Shipping Service Annotations • @Spy • @Mock • @InjectMocks Test Cases 1. Given a Valid Paid Order 2. Test for Packaging 3. Test for Shipping

Slide 110

Slide 110 text

@arafkarsh arafkarsh Annotation - @Spy 110 Scenario – 1 Create Mocks for the following 1. Packaging Service 2. Shipping Service Annotations • @Spy • @Mock • @InjectMocks Test Cases 1. Given a Valid Paid Order 2. Test for Packaging 3. Test for Shipping

Slide 111

Slide 111 text

@arafkarsh arafkarsh Annotation – @Spy 111 Scenario – 2 Create Mocks for the following 1. Packaging Service 2. Shipping Service Annotations • @Spy • @Mock • @InjectMocks Test Cases 1. Given a Valid Paid Order 2. Test for Packaging 3. Test for Shipping

Slide 112

Slide 112 text

@arafkarsh arafkarsh Annotation – @Spy 112 Scenario – 3 Create Mocks for the following 1. Packaging Service 2. Shipping Service Annotations • @Spy • @Mock • @InjectMocks Test Cases 1. Given a Valid Paid Order 2. Test for Packaging 3. Test for Shipping

Slide 113

Slide 113 text

@arafkarsh arafkarsh Advanced Features 113 Scenario Shipping Service with Delivery City Details for the final Shipment Mockito Advanced Features 1. Ordering the Input – InOrder 2. Argument Matcher 3. Counts 4. Built In Answer 5. Storing Arguments – Captor 6. Throwing Exceptions

Slide 114

Slide 114 text

@arafkarsh arafkarsh Advanced Features – InOrder 114

Slide 115

Slide 115 text

@arafkarsh arafkarsh Advanced Features – Argument Matcher 115

Slide 116

Slide 116 text

@arafkarsh arafkarsh Advanced Features – Count : External Calls 116

Slide 117

Slide 117 text

@arafkarsh arafkarsh Advanced Features – Built in Answers 117

Slide 118

Slide 118 text

@arafkarsh arafkarsh Advanced Features – Built in Answers 118

Slide 119

Slide 119 text

@arafkarsh arafkarsh Advanced Features – Captor : Argument Capture 119

Slide 120

Slide 120 text

@arafkarsh arafkarsh Advanced Features – Catching Exception 120

Slide 121

Slide 121 text

@arafkarsh arafkarsh SpringBootTest 2 With JUnit 5 121

Slide 122

Slide 122 text

@arafkarsh arafkarsh Spring Boot Test 122 1. Getting Application Context 2. Auto wiring the dependencies 3. JUnit 5 Based Examples ✓ This is required for WireMock and Pact Actual Payment Service Implementation is loaded

Slide 123

Slide 123 text

@arafkarsh arafkarsh SpringBootTest POM Config for JUnit 5 123 Exclude Default JUnit 4 SBT v 2.5.3

Slide 124

Slide 124 text

@arafkarsh arafkarsh Integration / Contract Testing o WireMock o Pact 124 4

Slide 125

Slide 125 text

@arafkarsh arafkarsh WireMock o Without SpringBootTest o With SpringBootTest 125

Slide 126

Slide 126 text

@arafkarsh arafkarsh WireMock Architecture 126 Service (Client) WireMock Request Mapping Response Data HTTP/S Calls

Slide 127

Slide 127 text

@arafkarsh arafkarsh Use Case – Order and Payment Service 127 Worker Nodes Order Pod Order Pod Order Pod Order Service N4 N3 MySQL DB EndPoints N2 Payment Pod Payment Pod Payment Pod Payment Service Service Call Kube DNS EndPoints 1. Order and Payment Service are loosely coupled. 2. Both need to be tested without any dependencies. 3. Payment Service is an External Service, So a Mock Server is required to do the integration Testing.

Slide 128

Slide 128 text

@arafkarsh arafkarsh WireMock – Setup 128 1. WireMock Mock Payment Server is setup. 2. Payment Service is initialized with Payment Gateway (Pointing to Mock HTTP Server). 3. Step 2 is required if SpringBootTest is Not used.

Slide 129

Slide 129 text

@arafkarsh arafkarsh WireMock – Payment Accepted 129

Slide 130

Slide 130 text

@arafkarsh arafkarsh WireMock – Payment Declined 130

Slide 131

Slide 131 text

@arafkarsh arafkarsh WireMock with SpringBootTest 131 Actual Payment Service & Config Implementation is loaded

Slide 132

Slide 132 text

@arafkarsh arafkarsh PACT o Consumer Driven Contracts o Provider Verification o Pact Broker o Comparison Mockito / WireMock / Pact 132

Slide 133

Slide 133 text

@arafkarsh arafkarsh Use Case – Product and Product Review Service 133 Worker Nodes Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB EndPoints N2 Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints Mongo DB 1. Product and Product Reviews are two Microservices getting developed independently. 2. Both need to be tested without any dependencies. 3. Contract is driven by Product Service (Consumer of Product Review).

Slide 134

Slide 134 text

@arafkarsh arafkarsh E2E Testing Vs. Integration Testing 134 Product Service Mock Provider Review Service Review Service Mock Consumer Product Service Break the Test into 2 independently testable units. Product Service Review Service End 2 End Testing is Time Consuming and Error Prone

Slide 135

Slide 135 text

@arafkarsh arafkarsh PACT Architecture – Consumer Testing 135 Product Service Mock Provider Expected Request Minimal Response Interaction • Pact = A contract between Consumer and Provider • Each Pact is a collection of interactions Compare Reply Expected Request Minimal Response Interaction Provider State Pact – Contract between Consumer & Provider Once the Consumer Testing is done Pact file is generated by Pact Framework Pact Broker Publish Pacts to Pact Broker pact-broker publish --consumer-app-version 1.0.0 --broker-base-url https://broker.com --broker-token SomeToken /path/to/pacts/consumer-provider.json --tag master $>

Slide 136

Slide 136 text

@arafkarsh arafkarsh PACT Architecture – Provider Testing 136 Review Service Mock Consumer Expected Request Minimal Response Interaction Provider State Compare Send Once the Consumer Testing is done Pact file is generated by Pact Framework Expected Request Minimal Response Interaction Provider State Pact – Contract between Consumer & Provider

Slide 137

Slide 137 text

@arafkarsh arafkarsh Pact Definition 137 Provider Name Consumer Name Contract Definition • @PactTestFor : Provider • @Pact : Consumer • Building Request / Response Pact

Slide 138

Slide 138 text

@arafkarsh arafkarsh Pact Definition 138 Consumer Name Contract Definition • @PactTestFor : Provider • @Pact : Consumer • Building Request / Response Pact • Running Consumer Pact Test

Slide 139

Slide 139 text

@arafkarsh arafkarsh Pact Contract JSON 139 1. Contract Defines the Provider and Consumer 2. N number of Interactions can be defined under a single Contract 3. Interaction Defines Request, Response, Provider States, Rules etc. 4. Pact Specs v3.0

Slide 140

Slide 140 text

@arafkarsh arafkarsh Pact : When to use? 140 ✓ Development of Consumer / Provider is controlled by your team/department/org. ✓ No. of Consumers are small for a given Provider ✓ Consumer and Provider are under active development. ✓ Consumer Driven Contract – Provider features are driven by Consumer. ✓ Provider team can easily control the data in the response. Pact is Good for When Source: https://docs.pact.io/getting_started/what_is_pact_good_for ✓ Both teams (Consumer & Provider) don’t use Pact. ✓ When the Consumers can’t be identified (Public APIs) ✓ Functional / Behavior Testing of the Provider ✓ Functionality is Driven by the Provider. ✓ Performance and Load Testing ✓ You can’t control the Response Data. Pact is NOT Good When

Slide 141

Slide 141 text

@arafkarsh arafkarsh Comparison – Mockito / Pact 141 # Feature Mockito WireMock Pact TEST SCOPE >>> API Wire Inter Service 1 Contract Testing Yes Yes Yes 2 Behavior / Functional Testing Yes 3 Test Double (Mock Provider) Yes 4 Consumer / Provider Testing using Shared Contract Yes 5 Mock System (For Consumer / Provider) Yes Yes 6 Multi Protocol Support (HTTP, Messaging) HTTP Yes 7 Centralized Contract Management Yes 8 API Documentation and Version Management Yes 9 Record and Playback Yes Yes 10 Supports JSON/XML Yes Yes

Slide 142

Slide 142 text

@arafkarsh arafkarsh Microservices Testing Scenarios / Tools 142 Testing Tools Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock Integration Contract Testing Scope Test Double Montebank Cart Component Testing Unit Testing Integration Testing Scope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing U

Slide 143

Slide 143 text

@arafkarsh arafkarsh Microservices Testing Strategies 143 E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 75% 25% 0% Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Architect

Slide 144

Slide 144 text

@arafkarsh arafkarsh Chaos Engineering – Load / Stress / Performance 144 Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Search for unused resources and disposes them. Compliance Monkey Finds instances that don’t adhere to best-practices and shuts them down. Latency Monkey Induces Artificial delays Security Monkey Is an extension of Compliance Monkey. Find security vulnerabilities and terminates offending instances. Source: https://github.com/Netflix/SimianArmy/wiki Source: http://principlesofchaos.org/

Slide 145

Slide 145 text

@arafkarsh arafkarsh Testing Strategy Summary 145 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects.

Slide 146

Slide 146 text

@arafkarsh arafkarsh Resources 146

Slide 147

Slide 147 text

@arafkarsh arafkarsh 147 https://speakerdeck.com/arafkarsh/

Slide 148

Slide 148 text

@arafkarsh arafkarsh 148 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns

Slide 149

Slide 149 text

@arafkarsh arafkarsh References 149 1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies

Slide 150

Slide 150 text

@arafkarsh arafkarsh References 150 1. Vmware: What is Cloud Architecture? 2. Redhat: What is Cloud Architecture? 3. Cloud Computing Architecture 4. Cloud Adoption Essentials: 5. Google: Hybrid and Multi Cloud 6. IBM: Hybrid Cloud Architecture Intro 7. IBM: Hybrid Cloud Architecture: Part 1 8. IBM: Hybrid Cloud Architecture: Part 2 9. Cloud Computing Basics: IaaS, PaaS, SaaS 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

Slide 151

Slide 151 text

@arafkarsh arafkarsh References 151 Microservices 1. Microservices Definition by Martin Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices

Slide 152

Slide 152 text

@arafkarsh arafkarsh References – Microservices – Videos 152 1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

Slide 153

Slide 153 text

@arafkarsh arafkarsh References 153 Domain Driven Design 1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

Slide 154

Slide 154 text

@arafkarsh arafkarsh References 154 Event Sourcing and CQRS 1. IBM: Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

Slide 155

Slide 155 text

@arafkarsh arafkarsh References 155 Kafka 1. Understanding Kafka 2. Understanding RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

Slide 156

Slide 156 text

@arafkarsh arafkarsh References 156 Databases: Big Data / Cloud Databases 1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?

Slide 157

Slide 157 text

@arafkarsh arafkarsh References 157 Docker / Kubernetes / Istio 1. IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring

Slide 158

Slide 158 text

@arafkarsh arafkarsh References 158 1. Feb 6, 2020 – An introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD

Slide 159

Slide 159 text

@arafkarsh arafkarsh 159 1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug‐ gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools

Slide 160

Slide 160 text

@arafkarsh arafkarsh References 160 CI / CD 1. What is Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application

Slide 161

Slide 161 text

@arafkarsh arafkarsh References 161 DevOps 1. IBM: What is DevOps? 2. IBM: Cloud Native DevOps Explained 3. IBM: Application Transformation 4. IBM: Virtualization Explained 5. What is DevOps? Easy Way 6. DevOps?! How to become a DevOps Engineer??? 7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg 8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM 9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE 11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU 12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

Slide 162

Slide 162 text

@arafkarsh arafkarsh References 162 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

Slide 163

Slide 163 text

@arafkarsh arafkarsh References 163 16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 21. CQS : http://en.wikipedia.org/wiki/Command–query_separation 22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 24. CAP 12 years how the rules have changed 25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 26. Pat Helland (Amazon) : Life beyond distributed transactions 27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 29. Rx Observable : https://dzone.com/articles/using-rx-java-observable