1 of 48

Mauricio Salatino

@salaboy

Laurent Broudoux

@lbroudoux

SIMPLIFYING CLOUD-NATIVE APP TESTING

ACROSS ENVIRONMENTS

2 of 48

Who we are!

Mauricio Salatino

@salaboy

Laurent Broudoux

@lbroudoux

CNCF Ambassador, Java Champion,

Dapr ecosystem @ Diagrid

Cloud native Architect @ Postman

Microcks founder

3 of 48

4 of 48

Agenda

  • Cloud Native Environments, Kubernetes and cross-environment portability challenges
  • Testing distributed applications, enabling teams to go faster
  • Dapr and Microcks

5 of 48

The Pizza App Demo 🪄

https://github.com/salaboy/pizza

6 of 48

7 of 48

8 of 48

9 of 48

10 of 48

11 of 48

12 of 48

13 of 48

14 of 48

How companies solve these challenges?

  • They use APIs to abstract away complexity
  • They create frameworks and tools that allow developers to be consumers of shared functionality
  • They abstract away the complexity of the different environments behind APIs, so operations teams can configure the same application to run across environments

15 of 48

Abstract away the complexity of a system behind APIs.

16 of 48

A different approach

Push the problem down to the runtime

17 of 48

18 of 48

19 of 48

20 of 48

21 of 48

22 of 48

23 of 48

Demo 🪄

24 of 48

Great, it runs on Kubernetes, but how do we run this locally

25 of 48

26 of 48

Demo 🪄

27 of 48

28 of 48

29 of 48

Oops… I added a

new service dependency…

30 of 48

DevEx & DISTRIBUTED APPS - WHAT A BURDEN!

$ mvn spring-boot:run

$ ./gradlew bootRun

$ npm run dev

$ ./mvnw quarkus:dev

$ make run

$ docker compose up -d

$ go run main.go

$ ./kafka-server-start.sh

$ postgres -D ~/pg-data

31 of 48

DevEx & DISTRIBUTED APPS - WHAT THE HELL!

The Developer’s Laptop

Service A

Service B

Service C

Database A

Database B

Database C

OK BUT …

LOTS OF COMPLEXITY

LOTS OF POWER / ENERGY

LOTS OF MONEY!

🔥

🔥

🔥

🔥

🔥

🔥

🔥

🔥

🔥

🔥

🔥

🔥

32 of 48

DevEx & DISTRIBUTED APPS -

TAKING SHORTCUTS

  • Avoid Testing Integrations
  • Use mock frameworks only
    • In-VM vs Network
  • Rely on your own vision

33 of 48

FROM DISTRIBUTED APPS to PROMISES to …

Services

& APIs

Promises

Contracts

34 of 48

MICROCKS

Turn Artifacts into light & smart simulations

INGEST

PROVIDE

MOCKS

WELL-KNOWN ARTIFACTS

🧠 SMART MOCKS

API Consumer

and others

35 of 48

MICROCKS

Turn Artifacts into Contract Testing Suite

INGEST

WELL-KNOWN ARTIFACTS

AUTOMATIC TEST SUITE

and others

VALIDATE

REAL API

API v1.2

API v1.1

API v1.0

API Provider

36 of 48

Inner or Outer Loops: Choice is yours!

Setup

Code

Build

Test

Push

Review

Build

Conform-ance

Security

Deploy

Inner loop

Outer loop

Pull/Merge Request

Developer

Team

Microcks

Microcks

Microcks

37 of 48

Demo 🪄

38 of 48

Contract Testing in Action!

  • Start your Application
  • Include a library like RestAssured
  • Call API endpoint and check:
    • Response status code
    • Response content-type
    • JSON evaluation
    • JSON response is valid on all paths
    • Loop on next call…

Typical approach

39 of 48

Contract Testing in Action!

  • Include Microcks and OpenAPI
  • Launch a Microcks Test

  • AssertSuccess

Microcks approach

: managed by Microcks Testcontainers tests

  • For all operations and examples:
    • Act as an API consumer
    • Validate OpenAPI schema

40 of 48

Usual Testing Nightmares (i) 😱

  • Include a mocking library
  • Prepare Mock object for DaprMessagingTemplate.send()
  • Check that messagingTemplate.send() has been called
  • Tear-down all resources

Typical “light” approach

41 of 48

Usual Testing Nightmares (i) 😱

Microcks approach

: managed by Microcks Testcontainers tests

  • Include Microcks and AsyncAPI
  • Launch a Microcks Test
  • Invoke KitchenService.emitEvent()
  • Start a Kafka broker
  • Check that messagingTemplate.send() has been called
  • + that message is sent over the wire
  • + that message is on correct Kafka topic
  • + that message is conformant to schema
  • Tear-down all resources

42 of 48

Usual Testing Nightmares (ii) 🤯

  • Prepare an Event object
  • Invoke PizzaStore.receiveEvents() handling function
  • Check that DeliveryService has been called
  • Tear-down all resources

Typical “light” approach

43 of 48

Usual Testing Nightmares (ii) 🤯

  • Include Microcks and AsyncAPI

  • Check that DeliveryService has been called
  • Tear-down all resources

Microcks approach

  • Start a Kafka broker
  • Publish mock messages on Kafka
  • Check that PizzaStore.receiveEvents() is connected and can read message
  • Check that consumer deserialization is ok

: managed by Microcks Testcontainers tests

44 of 48

Wrap-up

45 of 48

46 of 48

KEY LEARNINGS

  • Building distributed applications is hard…
  • Making these apps portable across environment is possible by using APIs, check out the Dapr Spring Boot integration!
  • Still, the Developer Experience can be a pain…
  • Microcks makes contracts finally useful!

for a better Developer Experience!

47 of 48

THANKS!!!

Mauricio Salatino

@salaboy

Laurent Broudoux

@lbroudoux

48 of 48

Feedback is Gold! 💛