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 folder we find:

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

gherkin_spec:

has.js

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

home-unit_spec.js:

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

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

feature example 1

feature example 2

feature example 3

compose

getAngular

getElement

getScope

load

Demonstration

The 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 https://hypermedia-orientation.surge.sh