Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Consumer-Driven Contract testing in Cookpad

March 31, 2017

Consumer-Driven Contract testing in Cookpad


March 31, 2017

More Decks by taiki45

Other Decks in Technology


  1. Consumer-Driven Contract testing in Cookpad Introduction of our software development

    and Pact as a Consumer-Driven Contract testing tool 5BJLJ0OP !UBJLJ
  2. 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
  3. 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..
  4. What we do • Solving problems around cooking ‣ To

    make everyday cooking fun ‣ Recipe sharing service ‣ Cooking school service ‣ and more..
  5. Products • Cookpad for sharing recipes in Japan • Cooking

    School • Video for cooking videos • News about cooking • and more..
  6. 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
  7. Our system architecture Cookpad app Cooking School app Video app

    … Auth Notification News app Payment …
  8. Teams and systems boundary Cookpad team Cooking School team Media

    team … DevInfra Cookpad app Cooking School app Video app … Auth Notification News app Payment …
  9. Building and releasing Github Enterprise Rundeck Test job Build job

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

    +FOLJOT Prod servers 1SPE %FQMPZ Slack "84&$4 PS&$
  11. 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
  12. Our approach • Simple stubbing ‣ Stub all HTTP requests

    using WebMock or VCR ‣ Problem: Can’t detect breaking changes of API
  13. 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.
  14. 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
  15. Pact • CDC testing tool • For Ruby, Java (JVM),

    Swift… • Also mentioned in “Building Microservices” book
  16. 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
  17. 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
  18. 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