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

Many people don’t like the Gherkin/Spinach/Cucumber approach to testing.

Why write the thing out in English and then just convert it to code?

Why set up the database and test environment configuration twice?

Cucumber’s step files are unmanageable!

To the first comment, I think I’ve explained why I prefer it. It’s describing the problem, taking what the customer has said and rephrasing, so that I’m proving to the customer that I understand what they want.

To the third comment, I say “that’s why I use Spinach”. Spinach’s step files are local to that one feature file, so everything’s in one place. If you really want to share stuff across features (such as “When I log in”) then you include it as a ruby module – so you can see the reference right there in your steps file.

But to the second comment – yeah, you’re right. It can be a pain. Especially when you have database cleaner set up in one and not the other.

So, especially, when writing APIs, I often use a different format.

In Rails I would add what Rails calls an “integration test”, but is just a full-stack test in a special folder with some extra stuff. In a non-rails project, I just add it amongst my other test folders, but it has a bit of extra setup (normally loading Rack::Test so I can simulate web-requests).

As I say, I like expressing the requirements in English. Ruby’s somewhat like English.

So we end up with a test looking something like this (in this case, using Minitest::Spec):

So it’s a mix of the two styles – the “Spec” style that Minitest takes from RSpec offers us English type descriptions, but we’re in code immediately with no translation.

I have to say, I still prefer the Gherkin style, but this is really good for APIs where your customer won’t actually care about what you write (remember, customers only care about results, not about your beautiful code).

Stay tuned to hear how TDD makes the rest of your life better … or sign up for a free Ruby on Rails security checklist below.

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

1 Comment How to write a full-stack test (part two)

  1. Pingback: How to write a full-stack test (part one) | The Art and Science of Ruby

Comments are closed.