Tweet
Tweet

Slide 1

Slide 1 text

Consumer-Driven Contract testing in Cookpad Introduction of our software development and Pact as a Consumer-Driven Contract testing tool 5BJLJ0OP !UBJLJ

Slide 2

Slide 2 text

This talk • Introduction of our software development ‣ What we do - our products ‣ Team organization and system architecture ‣ Building and releasing • Consumer-Driven Contract testing ‣ Problem and our approach ‣ What is Consumer-Driven Contract testing ‣ How it works in our environment ‣ Lessons we learned

Slide 3

Slide 3 text

Who is this speaker? • Taiki Ono (@taiki45 on the Internet) • Cookpad member since Mar. 2014 • Working in Developer Productivity team ‣ Goal: Keep developer’s productivity at high level ‣ Develop tools, build deployment system, design architecture and more..

Slide 4

Slide 4 text

Introduction of our software development

Slide 5

Slide 5 text

What we do • Solving problems around cooking ‣ To make everyday cooking fun ‣ Recipe sharing service ‣ Cooking school service ‣ and more..

Slide 6

Slide 6 text

Products • Cookpad for sharing recipes in Japan • Cooking School • Video for cooking videos • News about cooking • and more..

Slide 7

Slide 7 text

Product scale of Cookpad • over 63 million monthly active users in Japan *1 • 20,000+ test cases (It’s not related to product though) $PVOUTFWFSZBDDFTTGSPNPOFPGUIFEFWJDFTPSCSPXTFSTBCPWF

Slide 8

Slide 8 text

How our team are organized Cookpad team Cooking School team Media team … SRE DevInfra

Slide 9

Slide 9 text

Our system architecture Cookpad app Cooking School app Video app … Auth Notification News app Payment …

Slide 10

Slide 10 text

Teams and systems boundary Cookpad team Cooking School team Media team … DevInfra Cookpad app Cooking School app Video app … Auth Notification News app Payment …

Slide 11

Slide 11 text

Building and releasing Github Enterprise Rundeck Test job Build job +FOLJOT Dev servers Prod servers $BOBSZ %FQMPZ "84&$4 PS&$

Slide 12

Slide 12 text

Building and releasing Github Enterprise Rundeck Test job Build job +FOLJOT Prod servers 1SPE %FQMPZ Slack "84&$4 PS&$

Slide 13

Slide 13 text

Consumer-Driven Contract testing in Cookpad

Slide 14

Slide 14 text

Problem • Our architecture has been shifted from Monolithic to Microservices • Testing integration points became hard ‣ We tested them by usual test suites (in- process) before, but now components are separated ‣ Running real components are expensive and too fragile and slow

Slide 15

Slide 15 text

Our approach • Simple stubbing ‣ Stub all HTTP requests using WebMock or VCR ‣ Problem: Can’t detect breaking changes of API

Slide 16

Slide 16 text

rack-vcr • github.com/miyagawa/rack-vcr ‣ Capture HTTP req/res in server-side request (feature) tests. Then use them to replay server behavior in client-side tests.

Slide 17

Slide 17 text

How rack-vcr works

Slide 18

Slide 18 text

How rack-vcr works 'BJM $PNNJUCSFBLJOHDIBOHFT

Slide 19

Slide 19 text

Problem with rack-vcr 5IJTEPFTO`UTDBMF

Slide 20

Slide 20 text

Consumer-Driven Contract testing

Slide 21

Slide 21 text

Consumer-Driven Contracts (CDC) • “.. which imbues providers with insight into their consumer obligations, and focuses service evolution around the delivery of the key business functionality demanded by consumers.” • https://martinfowler.com/articles/ consumerDrivenContracts.html

Slide 22

Slide 22 text

Consumer-Driven Contracts

Slide 23

Slide 23 text

Consumer-Driven Contract testing

Slide 24

Slide 24 text

Pact • CDC testing tool • For Ruby, Java (JVM), Swift… • Also mentioned in “Building Microservices” book

Slide 25

Slide 25 text

How it works

Slide 26

Slide 26 text

How it works

Slide 27

Slide 27 text

Pact in Cookpad

Slide 28

Slide 28 text

Pact in Cookpad • github.com/taiki45/pact_junit_formatter

Slide 29

Slide 29 text

Good parts • We can detect breaking changes in CI ‣ Already detected breaking changes some times • We can do Test-Driven Development even in separated components development

Slide 30

Slide 30 text

Bad parts • We have to write too many tests ‣ Most of them are enough with type checking ‣ Since Ruby has dynamic type system, that type checking might be run in tests

Slide 31

Slide 31 text

Future works • Introduce type schema ‣ Write type definitions of API and check them in compile time or tests ‣ Use CDC tests in important or complicated integration points • Context naming problem ‣ It’s difficult to name “context” to keep consistency and uniqueness in entire name spaces