BDD for APIs
Jason Harmon
Jason Harmon
• Blogger on apiux.com
• API Architect @uShip
• Likes Python
• Works in everything else
• Funny mustache
• Lo...
Agile
• INDIVIDUALS AND INTERACTIONS
over processes and tools
–Inside our organization and with our
users
Agile
• WORKING SOFTWARE over
comprehensive documentation
–Not only in our product but our
testing & regression
Agile
• RESPONDING TO CHANGE over
following a plan
– APIs will change for your
business, better have tests
Agile
• CUSTOMER COLLABORATION
over contract negotiation
– Get good at sharing ideas
What is BDD?
• “Behavior Driven Development”
• English readable description of how our
product behaves
• Agreed upon by th...
* Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009)
http://lisacrispin.com/2011/11/08/us...
Q2 Automated & Manual Tests
Functional Tests
Examples
Story Tests
Prototypes
Simulations
SupportingtheTeam
Business Facing
Polyglot friendly
• Cucumber
– Ruby-based, the granddaddy of BDD
• Cucumber-JVM
– Java implementation, plays nice with Jun...
Gherkin
One Description to Rule Them All
• https://github.com/cucumber/gherkin
• Business Readable
• DSL
• Not code
Gherkin Example
Imperative Style
Scenario: Get nearby place name
Given I use the geonames host
When I access the resource ...
Gherkin Example
Declarative Style
Scenario: Get nearby place name
Given I use the geonames host
When I use the “Find Nearb...
Behavior Driven
• User experience trumps all
• API is no exception
• Treat API consumers like first class citizens
• Descr...
Step Definitions
Scenarios
“…until it’s green like a cuke”
Scenario outlines
Errors
Red means stop
Tags
Lots of power to selectively run groups of tests
Agreement
• Decide during planning how you will test for
Acceptance Criteria
• …AS A TEAM…
• Gherkin/feature definitions w...
Productivity
• Stakeholders know what they’re getting
• Devs know how to build it
• Testers know how to test it
• Product ...
Domain Language
• Focus on how you describe everything
• Find agreement on how to describe behavior
• Recognize when behav...
Share!
• All BDD tests can be committed to
SCM, including branches
• Provide process which allows collaborative
coding on ...
Continuous Integration
• Regression is running all the time
• Use tags to select the right depth of regression
• Very fast...
Samples
• Python/Lettuce
– https://github.com/jasonh-n-austin/api-bdd-tests
• Groovy/Cucumber-JVM
– https://github.com/jas...
Thank You
Jason Harmon
@jasonh_n_austin
http://jhr.mn
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
BDD for APIs
Upcoming SlideShare
Loading in...5
×

BDD for APIs

510

Published on

Supporting a talk by @jasonh_n_austin given to the @austinapi meetup on 9/25/13..
The usability of APIs has to be a forethought from product down to test. We must ensure a developer-focused mentality throughout the development lifecycle. BDD provides us with an elegant way to implement a plain English, plain text testing fixture, in a variety of languages.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
510
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

BDD for APIs

  1. 1. BDD for APIs Jason Harmon
  2. 2. Jason Harmon • Blogger on apiux.com • API Architect @uShip • Likes Python • Works in everything else • Funny mustache • Loves weiner dogs
  3. 3. Agile • INDIVIDUALS AND INTERACTIONS over processes and tools –Inside our organization and with our users
  4. 4. Agile • WORKING SOFTWARE over comprehensive documentation –Not only in our product but our testing & regression
  5. 5. Agile • RESPONDING TO CHANGE over following a plan – APIs will change for your business, better have tests
  6. 6. Agile • CUSTOMER COLLABORATION over contract negotiation – Get good at sharing ideas
  7. 7. What is BDD? • “Behavior Driven Development” • English readable description of how our product behaves • Agreed upon by the team: not Dev, QA or product owned • Used to verify the acceptance criteria for features in a product • Conceptually like TDD (test-first), but for functional testing (not code architecture)
  8. 8. * Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
  9. 9. Q2 Automated & Manual Tests Functional Tests Examples Story Tests Prototypes Simulations SupportingtheTeam Business Facing
  10. 10. Polyglot friendly • Cucumber – Ruby-based, the granddaddy of BDD • Cucumber-JVM – Java implementation, plays nice with Junit and all JVM languages (Groovy is quite nice here) • Specflow – .NET, Visual Studio integrated • Lettuce – Python-based, very similar to Cucumber • Behat – PHP-based
  11. 11. Gherkin One Description to Rule Them All • https://github.com/cucumber/gherkin • Business Readable • DSL • Not code
  12. 12. Gherkin Example Imperative Style Scenario: Get nearby place name Given I use the geonames host When I access the resource url "/findNearbyPlaceNameJSON" And I provide parameter "username" as "jharmon" And I provide parameter "lat" as "30.4754724" And I provide parameter "lng" as "-98.1564068" And I retrieve the JSON results Then the status code should be 200 And it should have a list "geonames" And the list should have at least 1 item
  13. 13. Gherkin Example Declarative Style Scenario: Get nearby place name Given I use the geonames host When I use the “Find Nearby Place by JSON” endpoint And I identify my “geonames” user credentials And I provide coordinates 30.4754724, -98.1564068 And I retrieve the JSON results Then it should have at least 1 valid "geonames" item
  14. 14. Behavior Driven • User experience trumps all • API is no exception • Treat API consumers like first class citizens • Describe how your API behaves from a consumer perspective
  15. 15. Step Definitions
  16. 16. Scenarios “…until it’s green like a cuke”
  17. 17. Scenario outlines
  18. 18. Errors Red means stop
  19. 19. Tags Lots of power to selectively run groups of tests
  20. 20. Agreement • Decide during planning how you will test for Acceptance Criteria • …AS A TEAM… • Gherkin/feature definitions will allow a ubiquitous language • Technically, this can get easier as the critical mass of your API interactions is in your testing framework, and scenario steps are predictable
  21. 21. Productivity • Stakeholders know what they’re getting • Devs know how to build it • Testers know how to test it • Product knows how to sign off • Documentation has a head start
  22. 22. Domain Language • Focus 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
  23. 23. Share! • All BDD tests can be committed to SCM, including branches • Provide process which allows collaborative coding on building test framework • Devs provide expertise on building a scalable test framework • Testers utilize existing step definitions to quickly build out tests
  24. 24. Continuous Integration • Regression is running all the time • Use tags to select the right depth of regression • Very fast identification of what’s broken
  25. 25. Samples • Python/Lettuce – https://github.com/jasonh-n-austin/api-bdd-tests • Groovy/Cucumber-JVM – https://github.com/jasonh-n-austin/TwitterRestTests • .NET/SpecFlow – https://github.com/jasonh-n-austin/TwitterRestTests
  26. 26. Thank You Jason Harmon @jasonh_n_austin http://jhr.mn
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×