BETTER API TESTING WITH OPENAPI SPECIFICATION TAYLOR BARNETT - - PowerPoint PPT Presentation

▶
better api testing with openapi specification
SMART_READER_LITE
LIVE PREVIEW

BETTER API TESTING WITH OPENAPI SPECIFICATION TAYLOR BARNETT - - PowerPoint PPT Presentation

May 10, 2023 177 likes •652 views

BETTER API TESTING WITH OPENAPI SPECIFICATION TAYLOR BARNETT @TAYLOR_ATX LEAD COMMUNITY ENGINEER @ STOPLIGHT TAYLOR@STOPLIGHT.IO @TAYLOR_ATX HI! [COMPANY] [BLEEPING] [BLEEPING] @taylor_atx Image by Paul Downey, CC by 2.0 SINGLE

slide-1
SLIDE 1

BETTER API TESTING WITH OPENAPI SPECIFICATION

TAYLOR BARNETT — @TAYLOR_ATX

slide-2
SLIDE 2

HI! 👌

LEAD COMMUNITY ENGINEER @ STOPLIGHT

TAYLOR@STOPLIGHT.IO

@TAYLOR_ATX

slide-3
SLIDE 3
slide-4
SLIDE 4

[BLEEPING] [BLEEPING] [COMPANY]

slide-5
SLIDE 5

@taylor_atx

slide-6
SLIDE 6

Image by Paul Downey, CC by 2.0

slide-7
SLIDE 7

SINGLE SOURCE OF TRUTH ☝

@taylor_atx

slide-8
SLIDE 8

SINGLE SOURCE OF TRUTH

▸ What does everything (humans and machines) look to? ▸ Messy, outdated design docs? ▸ Something that everyone agrees to - a contract

@taylor_atx

slide-9
SLIDE 9

OPENAPI SPECIFICATION

@taylor_atx

slide-10
SLIDE 10

Standard, structured approach for describing APIs that is both human and machine readable

@taylor_atx

slide-11
SLIDE 11

Image by OpenAPI Initiative

slide-12
SLIDE 12

OPENAPI SPECIFICATION

▸ Development contract ▸ Prototyping and mocking ▸ Client SDKs and libraries ▸ Testing ▸ Server stubs

@taylor_atx

slide-13
SLIDE 13

OPENAPI SPECIFICATION

▸ Simplifies describing an API ▸ Standardizes terminology ▸ “API Fastness”

@taylor_atx

slide-14
SLIDE 14

OPENAPI SPECIFICATION

▸ Good tutorial to walk through the specification: ▸ https://apihandyman.io/openapi/

@taylor_atx

slide-15
SLIDE 15

"OPENAPI IS A BRIDGE TO UNDERSTANDING AND BEING ABLE TO COMMUNICATE AROUND USING HTTP AS A TRANSPORT, AND OUR GREATEST HOPE FOR HELPING [PEOPLE] LEARN THEIR HTTPS AND 123S.” Kin Lane (@apievangelist)

@taylor_atx

slide-16
SLIDE 16

DESIGN-FRIST APIS ✍

@taylor_atx

slide-17
SLIDE 17

DESIGN-FIRST APIS

▸ Consistency for users ▸ Important for critical APIs ▸ Code-first can be expensive ▸ Gain the benefits of using OpenAPI

@taylor_atx

slide-18
SLIDE 18

CONTRACT TESTING

@taylor_atx

slide-19
SLIDE 19

Tests that ensure the API implementation meets the standards and definitions described in a contract

@taylor_atx

slide-20
SLIDE 20

CONTRACT TESTING

▸ Popularity has increased with the growth of microservices ▸ Some kind of contract available to all parties ▸ Enables independent deployments while not breaking other

people’s code

▸ What it is not testing: ▸ Service availability ▸ Load tolerance ▸ Deployment integrity

@taylor_atx

slide-21
SLIDE 21

VALIDATION SERVER API RESPONSE OPENAPI SPECIFICATION PASS OR FAIL

@taylor_atx

slide-22
SLIDE 22

BUT I ALREADY TEST MY APIS… 🤕

@taylor_atx

slide-23
SLIDE 23

(SOME) DIFFERENT TYPES OF TESTING

▸ Integration/Functional Tests ▸ Unit Tests ▸ End-to-end Tests

@taylor_atx

slide-24
SLIDE 24

(SOME) DIFFERENT TYPES OF TESTING

@taylor_atx

UI TESTING INTEGRATION TESTING UNIT TESTING

CONTRACT TESTING

slide-25
SLIDE 25

EXAMPLE: BROKEN SCHEMA 💕

@taylor_atx

slide-26
SLIDE 26

200 👎

curl --request GET --url http://api.taylorbar.net/hello-world

@taylor_atx

slide-27
SLIDE 27

@taylor_atx

slide-28
SLIDE 28

Test Greetings Scenario (0.009s) Hello World, GET http://api.taylorbar.net/hello-world (0.009s) ✗ hello: hello is required ✓ output.status (eq) 2xx ✗ 1 of 2 tests failed

😕

@taylor_atx

slide-29
SLIDE 29

SPEC API

{ “ello”: "world" }

@taylor_atx

slide-30
SLIDE 30

@taylor_atx

Test Greetings Scenario (0.012s) Hello World, GET http://api.taylorbar.net/hello-world (0.011s) ✓ output.body (validate.contract) against JSON Schema ✓ output.status (eq) 2xx ✓ 2 tests passed

😂

slide-31
SLIDE 31

Todo CRUD Scenario (0.831s) Create Todo, POST http://todos.stoplight.io/todos?apikey=123 (0.244s) ✗ user: user is required (root): Must validate all the schemas (allOf) ✓ output.status (eq) 201 Get Todo, GET http://todos.stoplight.io/todos/61904 (0.13s) ✗ user: user is required (root): Must validate all the schemas (allOf) ✓ output.status (eq) 200 Update Todo, PUT http://todos.stoplight.io/todos/61904?apikey=123 (0.137s) ✗ user: user is required (root): Must validate all the schemas (allOf) ✓ output.status (eq) 200 Delete Todo, DELETE http://todos.stoplight.io/todos/61904?apikey=123 (0.126s) ✓ output.status (eq) 204 ✓ output.body (validate.contract) against JSON Schema Make Sure Deleted, GET http://todos.stoplight.io/todos/61904 (0.192s) ✓ output.status (eq) 404 ✓ output.body (validate.contract) against JSON Schema ✗ 3 of 10 tests failed

@taylor_atx

😕

slide-32
SLIDE 32

SPEC API

{ "completed": null, "completed_at": null, "created_at": "2018-07-18T18:33:19.341Z", "id": 61907, "name": “feed Yoda", "updated_at": "2018-07-18T18:33:19.341Z" }

@taylor_atx

slide-33
SLIDE 33

Todo CRUD Scenario (0.902s) Create Todo, POST http://todos.stoplight.io/todos?apikey=123 (0.277s) ✓ output.status (eq) 201 ✓ output.body (validate.contract) against JSON Schema Get Todo, GET http://todos.stoplight.io/todos/61908 (0.141s) ✓ output.status (eq) 200 ✓ output.body (validate.contract) against JSON Schema Update Todo, PUT http://todos.stoplight.io/todos/61908?apikey=123 (0.145s) ✓ output.status (eq) 200 ✓ output.body (validate.contract) against JSON Schema Delete Todo, DELETE http://todos.stoplight.io/todos/61908?apikey=123 (0.129s) ✓ output.status (eq) 204 ✓ output.body (validate.contract) against JSON Schema Make Sure Deleted, GET http://todos.stoplight.io/todos/61908 (0.209s) ✓ output.status (eq) 404 ✓ output.body (validate.contract) against JSON Schema ✓ 10 tests passed

@taylor_atx

😂

slide-34
SLIDE 34

EXAMPLE: SDKS 🔦

@taylor_atx

slide-35
SLIDE 35

@taylor_atx

slide-36
SLIDE 36

ADD CONTRACT TESTING INTO CI/CD PIPELINE

@taylor_atx

slide-37
SLIDE 37

SDKS

▸ Helps maintainers ▸ Ensures API and SDK/libraries parity ▸ Go see Elmer Thomas’ talk at 5:05pm on “Managing SDKs

and their communities in multiple programming languages”

@taylor_atx

slide-38
SLIDE 38

EXAMPLE: DOCS 📅

@taylor_atx

slide-39
SLIDE 39

@taylor_atx

slide-40
SLIDE 40

WHAT ABOUT PACT TESTING?

@taylor_atx

slide-41
SLIDE 41

SINGLE SOURCE OF TRUTH PITFALLS

@taylor_atx

slide-42
SLIDE 42

SINGLE SOURCE OF TRUTH PITFALLS

▸ Forgetting the “why” ▸ Failing to version ▸ “version” is in the Info Object ▸ Bad communication

@taylor_atx

slide-43
SLIDE 43

COMMUNICATION

@taylor_atx

slide-44
SLIDE 44

@taylor_atx

slide-45
SLIDE 45

@taylor_atx

slide-46
SLIDE 46

THEY BECOME THE CODIFICATION OF A SET OF DISCUSSIONS ABOUT WHAT A SERVICE API SHOULD LOOK LIKE, AND WHEN THEY BREAK, THEY BECOME A TRIGGER POINT TO HAVE CONVERSATIONS ABOUT HOW THAT API SHOULD EVOLVE.

Sam Newman, “Building Microservices: Testing”

@taylor_atx

slide-47
SLIDE 47

TAYLOR@STOPLIGHT.IO @TAYLOR_ATX