BDD for APIs
-
Upload
jason-harmon -
Category
Technology
-
view
1.130 -
download
2
description
Transcript of BDD for APIs
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/