BDD for APIsJason Harmon

Jason HarmonBlogger @apiuxAPI Architect @uShip

Likes PythonWorks in everything else~20 years of tech experienceBackground in many integrations

What is BDD?“Behavior Driven Development”English readable description of how the product

behavesDefined by team up-front: not Dev, QA or product

ownedUsed to verify the acceptance criteria for features

in a productConceptually like TDD (test-first), but for

functional testing (not code architecture)

What BDD is NOTA testing framework

Really just an English-readable UI for your own testing implementation

A drop-in solutionYou have to write the code

A UI-testing solution, like SeleniumYou can actually use Selenium as a driver for Uis,

but we’re talking APIs!

* Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009)http://lisacrispin.com/2011/11/08/using-the-agile-testing-

quadrants/

Q2 Automated & Manual Tests

Functional TestsExamplesStory TestsPrototypesSimulations

Supp

ortin

g th

e Te

am Business Facing

BDD

Polyglot friendlyCucumber

Ruby-based, the granddaddy of BDDhttp://cukes.info

Polyglot friendlyCucumber-JVM

Java implementation, plays nice with Junit and all JVM languages

Groovy is quite nice herehttps://github.com/cucumber/cucumber-jvm

Polyglot friendlySpecflow

.NET, Visual Studio integratedhttp://specflow.org

Polyglot friendlyLettuce

Python-based, very similar to Cucumber

http://lettuce.it

Polyglot friendlyBehat

http://behat.org

GherkinOne Description to Rule Them All

Business ReadableDSL

Not codehttps://github.com/cucumber/gherkin

Gherkin ExampleImperative Style

Gherkin ExampleDeclarative Style

Behavior DrivenUser experience trumps all; APIs are no

exceptionTreat API consumers like first class citizensDescribe how your API behaves from a

consumer perspective

Step Definitions

Scenarios“…until it’s green like a cuke”

Scenario outlines

ErrorsRed means stop

Tags

Very useful for grouping features/scenariosAlso useful for ignoring

Prod

uct

Dev

elop

ers

Test

ers

Stak

ehol

ders

The way things used to be

AgreementDecide during planning how you will test for

Acceptance Criteria…AS A TEAM…

PushbackQA might be uncomfortable with code

Have dev help with a framework, QA can stick to feature files and simple step definition code

Dev might not be happy writing testsOnce they realize QA+PO signs off easy and fast,

they’ll be convincedProduct might just be afraid they have to code

or learn something “Techy”Once they realize it’s all about business lingo, i.e.

‘Domain Language’, they’re fine

ProductivityStakeholders know what they’re gettingDevs know how to build it, less reworkTesters know how to test it, more time to

exploreProduct knows how to sign off, and quicklyDocumentation has a head start

Domain LanguageFocus on how you describe everything

Find agreement on how to describe behavior

Recognize when behavior is different than before“Wait, we’ve never deleted before!”

Homework: Domain Driven Design

Share!

Share!All BDD tests can be committed to SCM,

including branchesProvides process which allows collaborative

coding on building test frameworkCode reviews on changes to test framework

are able to be automated

Continuous IntegrationRegression is running all the time

Use tags to select the right depth of regression

Very fast identification of what’s broken, in business language

SamplesPython/Lettuce

https://github.com/jasonh-n-austin/api-bdd-tests

Groovy/Cucumber-JVMhttps://github.com/jasonh-n-austin/TwitterRestTests

.NET/SpecFlowhttps://github.com/jasonh-n-austin/TwitterRestTests

Pull requests accepted!

Reading materialPosts on BDD with APIshttp://www.pragmaticapi.com/2013/01/12/bdd-atdd-for-your-agile-rest-api/http://www.pragmaticapi.com/2013/01/21/bdd-atdd-for-your-agile-rest-api-part-2/

ThanksJason Harmon

@jasonh_n_austinhttp://jhr.mn