Session slides from Future Insights Live, Vegas 2015: https://futureinsightslive.com/las-vegas-2015/ 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.

1. IS YOUR API MISBEHAVING?
D. KEITH CASEY, JR AUSTIN, TX
KEITH@CLARIFY.IO @CASEYSOFTWARE

3. The API for Audio & Video Data

4. http://TheAPIDesignBook.com

5. !
THE PROBLEM
BDD IN CONCEPT
BDD IN PRACTICE

6. ASSUMPTIONS

7. Assumption:
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

8. Assumption:
Nothing is perfect
I make mistakes
You make mistakes
Your providers make mistakes
Those other teams are knuckleheads

9. THE PROBLEM

10. API “testing” is Deceptive
Click tests - someone
Unit Tests - xUnit suite
Integration Tests - still probably xUnit
Web/UI Tests - Selenium, Watir, Testlio (mobile), etc

11. … no, seriously.
API Testing Sucks.

12. Two Goals
Prove* that it works (now)
Give you confidence (later)

13. Back to the Drawing Board
SMART
Specific, Measurable, Achievable, Relevant,
Time-boxed
INVEST
Independent, Negotiable, Valuable, Estimable,
Small, Testable

14. ENTER BDD

15. Behavior Driven Development
Standard Definition:
BDD is a synthesis and refinement of practices stemming
from TDD and ATDD.
Dan North’s Definition (circa 2009):
BDD is a second-generation, outside-in, pull-based,
multiple-stakeholder, multiple-scale, high-automation, agile
methodology. It describes a cycle of interactions with well-
defined outputs, resulting in the delivery of working, tested
software that matters.

16. Get your head out of the system!
What it really means..

17. What it looks like
As a [role] I want [feature] so that [benefit]

18. Well to be more precise
It’s English, but in the Gherkin syntax so this:
As a [role] I want [feature] so that [benefit]
becomes a feature called:
Given [condition] when I [action] then [result]

19. BDD IN PRACTICE

20. In Many Languages
Java - JBehave
Ruby - RBehave -> RSpec -> Cucumber
PHP - Behat
Python - Behave
C# - NSpec
Javascript - Cucumber-js & Jasmine

21. So let’s do this
Start small.

22. For Clarify.io
The first thing that anyone does:
Creates a bundle (audio or video package)
We need a file (audio in this case)
We need an API key
We need to submit it (POST)
We need to check the results (201 Created)

23. So let’s start writing!
Starting from scratch

24. Step 1
Write a feature!

25. Step 2
Refactor and reorganize things for reuse

26. Step 3
Implement our first step!

27. Step 4
Include a configuration

28. Step 5
Our first hard step: POST

29. Step 6
Look at the result

30. BDD IN PRACTICE (PART 2)

31. Step 7
Let’s add a simple read only test

32. Step 8
Refactor and reorganize things for reuse

33. Step N
Etc

34. BDD AT SCALE

35. And then…?
Write the feature
Refactor to reuse when possible
Add the left over bits
GOAL: You should be writing less and less code!

36. Our Status
We validate the Helper Libraries with this too
Feature tests for the API using:
Using the PHP library
Using the Python library
Using the Ruby library (newest)
(publicly launching our tests this month here: https://github.com/Clarify )

37. !
THE PROBLEM
BDD IN CONCEPT
BDD IN PRACTICE

38. IS YOUR API MISBEHAVING?
D. KEITH CASEY, JR AUSTIN, TX
KEITH@CLARIFY.IO @CASEYSOFTWARE

39. http://TheAPIDesignBook.com