Testing your APIs with Cucumber
BDD with Cucumber is gaining in popularity as it allows the expression of requirements using a custom domain-specific language that can be executed as tests to validate actual implementations. APIs in particular seem to have a lot to gain from this approach as they are often technical in nature; it seems that a correctly performed Cucumber implementation should allow increasingly non-technical stakeholders to participate in defining the requirements for an APIs behaviour and functionality.
But how "non-technical" can cucumber vocabularies be made to describe something as inherently technical as APIs? When does it make sense to use imperative vs declarative approaches? How do you translate simple language to complex payloads and validations? How does the usage of Cucumber scale as the complexity of an API increases? And how can standards like Swagger make cucumber testing even more intuitive? I know you're dying to find out - so don't miss this opportunity to adopt the path of API Gherkin Nirvana!
Worked with APIs 20+ years - created SoapUI far too many years ago - currently CTO at SmartBear working with Swagger and API Testing tools, and also chairman of the OAI guiding the evolution of the Swagger specification.