Is Your API Misbehaving?

Most API testing is a joke. We have things that resemble Unit Tests which are really integration tests which really just wrap our personal understanding in just a bit of code. And at the end of the day, we’re still not sure it works. Instead, let’s flip the entire experience around and look at it from the API consumer’s point of view and confirm that we’re solving real problems for real users. In this talk, we’ll dive into some of the benefits of Behavior Driven Development and walk through some examples.

Transcript

1. Is Your API Misbehaving? D. Keith Casey Jr keith@clarify.io @CaseySoftware
2. Who am I?
3. Who am I? Clarify.io - The API for businesses to build apps that Search and Understand their Audio & Videos
4. Who am I? http://TheAPIDesignBook.com
5. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
6. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
7. Assumptions • You have a technical background • APIs are an important part of your job • Use them on a regular basis • Potentially build them too • Sometimes public, sometimes private 7
8. Assumptions • Nothing is perfect • You make mistakes • Your providers make mistakes • That other team are knuckleheads 8
9. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
10. • Click Tests - someone • Unit Tests - xUnit suite • Integration Tests - still probably xUnit • Web/UI Tests - Selenium, Watir, Testlio (mobile) API Testing is Deceptive 10
11. … no seriously. API Testing Sucks 11
12. Two Goals Prove* that it works (now) Give us confidence (later) 12
13. Back to the Drawing Board 13 • SMART • Specific, Measurable, Achievable, Relevant, and Time-boxed • INVEST • Independent, Negotiable, Valuable, Estimable, Small, Testable
14. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
15. BDD - Standard Definition 15 BDD is a synthesis and refinement of practices stemming from TDD and ATDD
16. BDD - Dan North 16 BDD is a second-generation, outside- in, pull-based, multiple-stakeholder, multiple-scale, high-automation agile methodology. It describes a cycle with well-defined outputs, resulting in the delivery of working, tested software that matters.
17. BDD - What it really means 17 Get your head out of the system!
18. BDD - What it looks like 18 As a [role], I want [feature] so that [benefit]
19. BDD - To be more precise 19 It’s English but in the Gherkin syntax so this: • As a [role], I want [feature] so that [benefit] becomes a feature (or spec) structured as: • Given [condition], when I [action] then [result]
20. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
21. In lots of languages 21 • Java - JBehave • Ruby - RBehave -> RSpec -> Cucumber • PHP - Behat • Python - Behave • C# - NSpec • Javascript - Cucumber-js & Jasmine
22. So let’s do this! Start small.
23. At Clarify.io 23 • The first thing everyone does: • We want to search audio • We need an API key (use the docs key) • We need to submit a search query (GET) • We need to check the results (200 OK)
24. Step 1 24 Write the feature!
25. Step 2 25 Refactor for reuse (not this time, but usually)
26. Step 3 26 Run the Specs!
27. Step 4 27 Implement our Step until it passes
28. Step 5 28 Our first challenge: GET
29. Step 6 29 Goto 3
30. At Clarify.io (cont) 30 • The second thing everyone does: • We want to search our own audio • We need an API key (use our key) • We need an audio file • We need to submit it (POST) • We need to check the results (201 Created)
31. Step 1 31 Write the feature!
32. Step 2 32 Refactor for reuse (not this time, but usually)
33. Step 3 33 Run the Specs!
34. Step 4 34 Implement our Step until it passes
35. Step 5 35 Our first challenge: POST
36. Step 6 36 Goto 3
37. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
38. And now what? 38 • Write the feature • Refactor to reuse steps when possible • Add the missing bits • GOAL: • We should be writing less and less code!
39. Our Status 39 • We validate our helper libraries with this too • One set of features/specs for the API using: • the PHP library • the Ruby Gem • the Python library (underway) We’ll launch them publicly soon - https://Github.com/Clarify
40. • Assumptions • The Problem • Enter BDD • BDD in Practice • BDD at Scale • Next steps…
41. todo next? 41 Lots of things!
42. D. Keith Casey Jr keith@clarify.io @CaseySoftware Is Your API Misbehaving?
43. Who am I? http://TheAPIDesignBook.com