Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui, Elizabeth White

Related Topics: @DevOpsSummit, Microservices Expo, Open Source Cloud, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Blog Feed Post

API Design Using Behavior | @CloudExpo #API #DevOps #Microservices

It's easy for us as programmers to become focused on the details of our system

API Design Using Behavior Driven Development
by Erik Dietrich

Test-driven development (TDD) has been around for a while now.  Behavior-driven development (BDD), a comparably recent methodology, emerged from the practice of TDD and could reasonably be called a narrower application of TDD.

The TDD process allows a developer to use a failing unit test to express a shortcoming of the system.  The next step is to modify the production code to get the failing test to pass without making existing tests fail.  BDD more or less takes this same concept and adds the idea that the tests should be written in easy-to-understand language describing the problem domain, and that tests should express user acceptance criteria.

So instead of

void testErrorMessageOnNull()
you would have

Given a text box that has been left empty, when I click submit, I should receive an error message.
As a practice, this has found its way into the agile canon. It has given rise to something conversationally termed "three amigos," in which a representative of "the business," a tester, and a developer get together and agree on a few things: what the requested feature is, what it means, what it looks like when done, and how to verify completion.  In teams practicing BDD, the output of this conversation will often be an acceptance test, expressed in the Gherkin specification language.  When added to the codebase, this test will, of course, fail.  The folks implementing the feature know that they're done when they've succeeded in making the test pass.

If we put agile aside for a minute, this is a pretty commonsense approach for any team.  The essence of it is, "let's define and be clear about what success looks like and then automate a check for it."  So you don't need to be an agile team for this to make sense - you just need to be a team looking for clarity.

BDD in the API Provider World
Everything about BDD makes perfect sense in the line-of-business and traditional product development worlds.  In those worlds, "the business" wants stuff from "the geeks," and that basic operating paradigm creates the need for something like Gherkin to be necessary.  As elegant as it may seem, Gherkin could easily be viewed as pidgin developer-business talk.

But what happens when you're in the business of making products for developers?

I've worked with teams in the past that built a product with no user interface, to be consumed only by other software developers.  For teams like this, the people on and around the team may all have software development chops.  Testing is achieved through first-class programming automation.  People that function as project managers or business analysts are comfortable discussing the details of a method invocation or POSTing JSON to an endpoint.  The business is entirely technical, so there is no understanding deficit among the team members when talking shop.

So BDD doesn't apply for such teams, then, right?

Actually, it does.  In fact, I believe that it applies just as much to a project with technical consumers as it does to a project with business or public consumers.  And the reason for this is relatively simple.  While it may seem counterintuitive, BDD isn't ultimately about finding common ground in the language between "business people" and "geeks."  It's about being clear about what users can expect from a system, using terms both users and developers can agree on.

To be clearer about this, let's consider a problem domain for reselling tickets to events.  If we were building a website to be consumed by the public, we might write an acceptance test that's something like the following to drive system behavior:

Given there are 2 tickets available for the Rolling Stones Concert
When I request all tickets for the Rolling Stones Concert
Then I see 2 tickets
This test would call into the presentation/controller logic of the web application. It would seed the application with two available tickets, make a request for all tickets, and then verify that the two tickets were returned.

But what if there were no website? What if the product was just a backend service for a series of resellers to use to drive their own sites? In that case, our users would be the developers at those reseller companies. In that case, why not write a test like the following?

Given there are 2 tickets available for the Rolling Stones Concert
When I issue a GET to ~/concerts/RollingStonesConcert
Then I receive JSON with 2 ticket entries
Most people aren't used to Gherkin that looks like this, but it's perfectly valid.  The language is intended to describe your application's behavior in the terms of its domain.  And if your product is an API that provides this service, HTTP verbs, JSON, resource paths, and entries are part of your domain (along with tickets and concerts).

Representing Your Users
It's easy for us as programmers to become focused on the details of our system.  What's the performance like?  What should the preconditions and invariants be for this object instance?  Have we considered all the edge-case scenarios for this call?  And it's doubly easy to get caught up in these sorts of details when our users are fellow programmers who would be completely empathetic.

Don't get me wrong.  The details are important - very much so.  But the way users perceive and interact with your system is just as important, if not more so.  BDD forces you to think about that.  It forces you to form a common understanding of what success looks like with the people that are using your system.  The fact that you work on a technical product isn't a reason to pass on that opportunity. It's a reason to double down on it.

this didn't make sense to me the way it stood-"be written in language about ." I still don't know if it makes sense.

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

@DevOpsSummit Stories
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DXWorldEXPO LLC announced today that Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
This session will provide an introduction to Cloud driven quality and transformation and highlight the key features that comprise it. A perspective on the cloud transformation lifecycle, transformation levers, and transformation framework will be shared. At Cognizant, we have developed a transformation strategy to enable the migration of business critical workloads to cloud environments. The strategy encompasses a set of transformation levers across the cloud transformation lifecycle to enhance process quality, compliance with organizational policies and implementation of information security and data privacy best practices. These transformation levers cover core areas such as Cloud Assessment, Governance, Assurance, Security and Performance Management. The transformation framework presented during this session will guide corporate clients in the implementation of a successful cloud solu...
So the dumpster is on fire. Again. The site's down. Your boss's face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke. Yes, we know this is a developer's fault. There's plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone's job. But we're civilized now. Sort of. So we call them post-incident reviews. Fires are never going to stop. We're human. We miss bugs. Or we fat finger a command - deleting dozens of servers and bringing down S3 in US-EAST-1 for hours - effectively halting the internet. These things happen.