[LRUG] Writing readable feature tests with RSpec

[Zetter]

I wrote the original blog post with the rest of the FutureLearn team.
Since Joel posted it to the list there has been of lots of great
discussion of RSpec and Cucumber features. To help my own
understanding, I've tried to summarise some of what's been said so
far:


# Better RSpec features

+ In the post I gave the example where we've extracted everything into
a method. Andrew F said he extracts some parts for code re-use, and
also suggests writing custom RSpec matchers.

+ Vincent Bonmalais mentioned page objects as another way to improve
readability and organise code.

+ Tom Stuart explained how to use RSpec's `config.alias_` method to
set up 'feature' and 'scenario' (or any) keywords in RSpec without
requiring capybara.

+ Paul Battley had a go at refactoring some existing RSpec features,
and prefers how any state introduced in the test is kept to the file.

+ Paul Battley, Sam Livingston-Gray & Murray Steele suggested ways of
dealing with the problem of not always being able to reuse methods
written in the readable style- e.g. using a 'given_x' as a 'and_x'.
After using this style of specs for a while at FutureLearn, I've found
that there has been very few instances that we've had this problem. I
don't know if it's something about the way that we are writing
features that makes this so, is there anyone having this problem able
to share an example feature? My response to a similar question:
https://about.futurelearn.com/blog/how-we-write-readable-feature-tests-with-rspec/#div-comment-63271


# The joys of using Cucumber

+ Tom Stuart linked to some notes on how he uses Cucumber
http://codon.com/notes-on-counting-tree-nodes#tools

+ Sam Livingston-Gray talked about Cucumber and the trade offs when
using it. Sam makes the point that a similar strategy could have been
used by us to write more maintainable Cucumber.

+ Andrew Premdas explains how the global `World` space is a good thing
because it forces you 'differentiate each key concept by its name' and
'limit the number of concepts' in your application. Anthony Green
linked to a talk about `World`:
https://skillsmatter.com/skillscasts/3948-working-in-the-cucumber-world


# Better Cucumber

+ Aslak Hellesøy, on that Cucumber is a tool for collaboration.
https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

+ Sam Philips says that Cucumber suits teams with a 'highly technical
PM/BA' which rarely exists.

+ Andrew Premdas says regexes are a big no for Cucumber, I would go
further and think that any parameter passing is too much? Andrew gives
another example later around writing sign in steps which avoids using
any parameters.

+ Kerry Buckley suggests Cucumber-vim to jump between method (in which
I found the longest one-line regexp I've seen for a while:
https://github.com/tpope/vim-cucumber/blob/e1728c/ftplugin/cucumber.vim#L53
)

+ Graham Ashton, Will and others have talked about how important the
'discovery' phase is of a project/feature and that it's not worth
introducing Cucumber after this stage (rather than using it to drive
it). There's a recommended talk by Liz Keogh
http://youtu.be/2EM4itu7j7I & http://youtu.be/AFCdE5KSREI . At
FutureLearn we use PivotalTracker (and conversations) to build up user
stories before we start implementing them which might show that we
weren't getting all the benefits of Cucumber that others do.

+ Sam Livingston-Gray suggests that Cucumber steps can be easier to
debug if you use a global `Hash` instance to store state and
`Hash#fetch` to retrieve them rather than instance variables.


# Better user stories

+ Graham and Will reminds us that  'As a...I want to..' is not the
only way to write user stories that and can be limiting.
https://leanpub.com/50quickideas suggests other ideas.

+ Anthony Green shared a link to 'The (Untapped) Power of User
Stories' talk https://skillsmatter.com/skillscasts/5099-the-untapped-power-of-user-stories


# Other testing Tools

+ Turnip, lest you write Gherkin features and define the steps in
RSpec- https://github.com/jnicklas/turnip

+ RSpec Longrun, lets you group together sections of specs into
'steps' and get timing details from them
https://github.com/mdub/rspec-longrun

+ RSpec Given, adds 'Given', 'When', and 'Then' blocks to RSpec
https://github.com/jimweirich/rspec-given



I think you can go wrong writing features in Cucumber and RSpec. It's
not simple to make the case that you're more or less likely to write
good features with one or the other. I don't think it's clear from the
blog post that our switch to our new style of writing RSpec was to
solve some specific problems that we were having:

+ We found Cucumber harder to write & maintain and didn't feel we were
getting enough benefit from it to justify this. This manifested itself
by no one on the team wanting to modify or create Cucumber features,
instead preferring to write RSpec features.

+ Our RSpec features were hard to follow because. Particularly, it was
hard to see the user feature or journey from reading the specs.

The 'best of both' approach feels right for us and we have no
complaints so far. I'm still interested to hear from anyone using this
approach that has come across problems after using it over a longer
time.

Chris Zetter




On Fri, Jul 25, 2014 at 10:26 AM, Joel Chippindale
<joel.chippindale at futurelearn.com> wrote:
> We recently blogged about how, at FutureLearn, we write readable feature
> tests with RSpec*, see
> https://about.futurelearn.com/blog/how-we-write-readable-feature-tests-with-rspec/,
> and it made me wonder how common this approach was.
>
> Are any of you using this approach already? If so, how are you finding it?
>
> J.
>
>
> * Hat tip to the developers at Econsultancy who introduced me to this way of
> using RSpec.
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>