Automated Acceptance Testing with Cypress (wip)

Typically our stories’ Acceptance Criteria depart like so:

As a user, I want to ...

This is well enough for conveying the intent of the feature to be developed amongst human readers who understand the implications and make inferences about what doing the right thing might look like but in many cases, the existing product already has some pattern of interaction to recreate for novel cases. However, the problem concerns what kind of user is at play: is it a human or is it a machine reading the interface of the application? And furthermore, can we automate the user’s interaction in some way that tells us we’ve borked the existing UI. Traditionally, of course, this task is for a QA team who work with various amazing tools for accomplishing such requirements. But in truth, this is a developer experience requirement. Why should a front end dev need complicated and awkward test scripts like Protractor? And obviously unit tests won’t do. If the developer wants to write a test, it would improve their experience to have tests that are easily written in a Gherkin-style syntax, where an underlying framework processes the simple files and maps VERBs and NOUNs, of plain, common, ubiquitous language, to generic behaviors scriptable in JavaScript. I’ll be giving a demostration of doing this with Cypress.

First, we need to sort out where all our files are, in the cypress folder we find:

The important files I’ve worked on here are in integration and videos (the outcome of a executed integration). Let’s get started (pardon the sloppy code):



This is a common utility that both Cypress and Protractor depend on:


As the reader may see, I have a bit going on here already. Take the naming schemes with a grain of salt. In my tests/bdd folder we find:

The utils folder should be self-explanatory, and the toys inside just as well:

feature example 1

feature example 2

feature example 3







The home-unit_spec.js is a bit disheveled anyway, but it’s really only a “standard” Cypress approach (albeit filtered through my poor coding habits). So we’ll just show what the Gherkin generalization metaspecification executes (I’m calling it a “metaspec” because of the introduction of Gherkin-style format and the presumption of thinking in terms of ubiquitous language, or “domain language”).




nobody leaves the cave before the end of a new dawn

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Timber Mod 1.16.4/1.15.2/1.14.4 —

Timber Mod 1.16.4/1.15.2/1.14.4

Learn Fast, Fail Fast, Deliver Fast, Introducing Docker to the Enterprise

Postman Hack The Box (HTB)

This Is Why Your DevOps Tools Are Costing You Uptime

These Are The Programming Languages Microsoft Uses

Discord bots are over

Data Structures in Real Life

The difference between Metaverse and Digital Twins

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
⚫️ nothingness negates itself

⚫️ nothingness negates itself

nobody leaves the cave before the end of a new dawn

More from Medium

Introduction to progressive web applications (PWAs)

The Virtue of CORS

How to use .foreach in Javascript