How to write a full-stack test (part one)

So, you’ve decided to make your application more boring. That’s great. Your boss may hate you in the short-term, but your clients will love you and their love will make your boss smile. And even better, you’ll be smiling too.

But how do you do this?

There are a few ways of handling this – and I change my mind on which way is best weekly. Which shows that the process is still flawed; it’s not a silver bullet. It can be slow. It can be frustrating. It can be a pain in the arse.

Despite this, it’s still better than not having full-stack tests.

I promise.

The most common method I use is Spinach. Spinach is very similar to the more common Cucumber tool, although there is an alternative method I use for some projects (or both in one project), which I’ll explain another day.

The key fact, with both Spinach or Cucumber, is that you can write your specifications in English. Well, not quite English, a language called “Gherkin”.

These people love their fruit and veg.

A lot of people don’t like writing their stories in Gherkin.

Gherkin is just a compromise; the feature is described at a high-level and not much more use than comments.

Well I disagree.

My clients love Gherkin.

Client responding to a Spinach story

I take their documents, rewrite as Spinach stories, send them back and they ask me questions, write up suggestions and include things I’ve omitted. The image above is a real story that went live a few weeks ago. The feedback is real, from an office manager, not a technocrat.

And, most importantly, they feel involved in the process.

Software development is scary to clients. They are handing over a large sum of money to buy something they don’t really understand.

Gherkin invites them in to the heart of the process, in a way that they can understand.

And then they think of you as a better developer; you speak to them in their own language, not techno-babble.

Another benefit is personal; having rewritten the story in Gherkin format, I feel like I understand it better and I know where its limits are. I know when the feature done. I know what’s important and what isn’t important.

If I went straight to writing code instead of English I would lose that helicopter view.

So, given that, what goes in to a story?

One of the issues with these full-stack tests is that they are slow. Especially when Javascript is involved (and in fact, the most frustrating thing is when testing Javascript apps, you need to wait for responses and get weird timing issues – I never said it was going to be easy).

So I tend to write a minimal amount of the specification.

What is known as the “Happy Path“.

Write out what happens when the user does all the right things, all the data is in the correct format and the entire universe is aligned in your favour.

Don’t write out the details of individual fields and text-boxes, just “I add a widget to the thingy”. Don’t specify individual menu items, just “I navigate to the document”. Don’t write out the error conditions. Don’t write out what happens when you’re not logged in. Or don’t have the right permissions.

Just the good stuff. As succinctly as possible.

You’re not writing a novel.

You just want to prove that your app does what it’s supposed to do.

That’s all the full-stack test does.

As for the stuff it’s not supposed to do, we can catch that in a later phase; the discovery tests. And we’ll get to them later, plus another way of writing these tests (or sign up below to get weekly updates along with a free Ruby on Rails security checklist)

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe