[LRUG] Writing readable feature tests with RSpec

Will william at theappbusiness.com
Sat Jul 26 07:51:59 PDT 2014


I've had very similar conversations with quite a lot of Ruby developers 
on this topic. I agree with the sentiment that cucumber can work well, 
and I'd advocate the approaches suggested.

But the majority of Ruby developers, I've either interviewed or worked 
with, much prefer RSpec. Of all the arguments against I've heard, these 
are the typical ones (some of these already mentioned on this thread):

1). cucumber is slow

99% of the time what they are referring to turns out to be the 
implementation of tests being slow not the framework itself

2). cucumber is bloated

probably a fair criticism. RSpec isn't compact either but there has been 
acknowledgement of this problem from cucumber contributors 
(http://blog.mattwynne.net/2012/04/26/a-vision-for-cucumber-2-0/ and 
https://groups.google.com/forum/#!msg/cukes/a6KmuoWiCJE/M_s7uIgNDW0J). 
It seems like something that is there to be addressed though & on the 
roadmap, although it will take some time.

3). product owners never end up reading or contributing to cucumber 
tests, so why bother with gherkin

even if this is the case, there's value in clearly specifying the key 
features of any application using domain language. This way any new 
developer or other team member can grasp this without knowing the code. 
 From my experience, it is possible to get product owners contributing, 
even it takes a bit of work to make it easy for them. With initiatives 
like https://cucumber.pro/ and https://www.relishapp.com/, who knows it 
might get easier.

The patterns for RSpec discussed improve readability, and are something 
I'd go for if working on feature/request specs, but (in my opinion) it's 
still not quite up there with a plain text scenario. You can also use a 
DSL provided by libraries like turnip, which gives you the opportunity 
to use a gherkin syntax in RSpec though.

4). why have two test frameworks?

if you keep your test logic in pure ruby code like people have 
mentioned, you can:
- share helpers across RSpec and cucumber relatively easily (if you want 
to);
- establish some common standards and patterns;
- have test code that any ruby developer can read, in both suites.

It can be useful to separate acceptance/end-to-end tests and lower-level 
unit & component tests e.g. if the acceptance tests need different setup 
such as background workers running, search indexes populated, etc. Doing 
this for all tests might be unnecessarily slow your lower-level test 
down if those are all you need to run. Depends on the codebase & the 
team, I guess.

You can use RSpec metadata and request types to separate these concerns 
too; it's a bit more fiddly.

  5). regexes and step definitions are much less readable than method 
calls with parameters

something picked up on already, and something I can understand. But as 
people have pointed out, there are patterns you can apply that make this 
less of an issue. The ideas in turnip around improving this are 
definitely interesting though.


Aside from all these points, a couple of other relevant things I've come 
across on the topic:

  * http://myronmars.to/n/dev-blog/2013/07/the-plan-for-rspec-3 - a blog
    post from a core RSpec contributor with this quote:


"RSpec originated in a time before the existence of Cucumber/Gherkin, 
and one of its early goals was to express things in natural language 
that a project stakeholder could understand. In those early days, an 
expression like team.should have(9).players made sense for the goals of 
the project. Since then, Cucumber/Gherkin have emerged as a better 
alternative for stakeholder-focused tests, and RSpec is rarely used for 
that purpose today."

RSpec uses cucumber to produce exectuable specs for its own codebase 
(https://relishapp.com/rspec); could be a sign that it'll have more 
focus on supporting testing at the unit & component level going forward?

  * http://blog.mattwynne.net/2012/04/26/a-vision-for-cucumber-2-0/ - a
    blog post from a core cucumber contributor


This references the original developer of Turnip, saying 'Using RSpec as 
the runner for Turnip hasn’t worked out so well.' Would love to know 
more about why and whether this is still the case.

  * For some reason you have to add capybara to your gemfile to use the
    feature/scenario syntax in RSpec feature specs. I work on a lot of
    APIs, so really don't need capybara as a dependency.

  * In Cucumber, I don't think the approach of adding modules to the
    World object is clean way to reuse code. It makes them accessible in
    all step definitions without namespacing. It does seem to be the
    most documented approach though. I generally leave my ruby code in
    the support folder and just access it within the step definitions
    using the fully-qualified names.


Both frameworks have their pros & cons. Personally, I prefer Cucumber 
over RSpec feature & request specs. as has no doubt come across. But, 
the overwhelming resistance to cucumber within the community is 
difficult to ignore. For now, I remain unconvinced by a lot of the 
arguments against Cucumber.

I should say though, both are great libraries & I'm definitely very 
grateful to their contributors!



*Will Thomas
*

The App Business
20-24 Broadwick Street
London W1F 8HT
+44 203 657 9785
www.theappbusiness.com <http://www.theappbusiness.com/>

Join the team: we're now 75+ strong and growing fast 
<http://www.theappbusiness.com/careers/>
The Drum Census 2013: ranked UK No.1 with 1-50 staff 
<http://www.thedrum.com/digital-census/2013>

Check out our latest thinking in our journal 
<http://www.theappbusiness.com/journal/> and follow us on:
Twitter <http://twitter.com/theappbusiness> • LinkedIn 
<http://www.linkedin.com/company/the-app-business> • Google+ 
<http://www.google.com/+TheappbusinessTAB> • Dribbble 
<http://dribbble.com/theappbusiness> • Instagram 
<http://instagram.com/theappbusiness> • Facebook 
<http://www.facebook.com/theappbusiness>


The App Business Limited is a company registered in England and Wales
Registered number: 01897720


> Paul Battley <mailto:pbattley at gmail.com>
> 26 July 2014 14:17
>
> Brilliant! Somehow I never realised that. Despite having a version of
> vim-cucumber *that actually supports jumping*, I was absolutely sure
> that it wasn't possible. And absolutely wrong.
>
> Paul.
> _______________________________________________
> 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
> Kerry Buckley <mailto:kerryjbuckley at gmail.com>
> 26 July 2014 12:32
> On 26 July 2014 at 12:30:13, Paul Battley (pbattley at gmail.com 
> <mailto:pbattley at gmail.com>) wrote:
>
> Cucumber-vim supports jumping to step definitions with ctrl-].
>
> Kerry
>
> _______________________________________________
> 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
> Paul Battley <mailto:pbattley at gmail.com>
> 26 July 2014 12:30
>
> All other considerations aside, I find that the use of string matching
> for dispatch is an inconvenience when working with Cucumber. In my
> editor[1], I can go straight to the definition of a method just by
> pressing a key combo[2], which really helps in navigating unfamiliar
> code. With Cucumber, I have to use a lucky guess or just grep for a
> distinctive bit of the string.
>
> Of course, *I* always put my own definitions in sensible places etc.
> etc., but in reality most projects are collaborative and even though
> all our collaborators are intelligent and well-meaning people, we
> don't all think in exactly the same way.
>
> Perhaps it's just a tooling problem - perhaps it's already been solved
> and I'm just blissfully ignorant! - but I do think that Cucumber's
> string matching presents a concrete difficulty, especially on larger
> projects and teams, and I think that this problem exists regardless of
> any overuse of parameters within regular expressions.
>
> Paul.
>
> 1. Vim with ctags and Ctrl-].
> 2. Unless someone's taken the metaprogramming too far, of course.
> _______________________________________________
> 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
> Andrew Premdas <mailto:apremdas at gmail.com>
> 26 July 2014 01:24
>
>
>
> On 25 July 2014 11:46, Murray Steele <murray.steele at gmail.com 
> <mailto:murray.steele at gmail.com>> wrote:
>
>     I really liked that article because it matches how I write rspec
>     features :)
>
>     I like cucumber because of how it makes me think about what the
>     user journey I’m testing is actually about and for, but I dislike
>     cucumber because I think the regexp matching for step definitions
>     places an unnecessary burden on the developer.
>
>
> This is really unfortunate. The fact that regex's are there in 
> Cucumber means that you 'can' do all sorts of stupid things with them. 
> If you do that will be a burden. However it doesn't mean you should do 
> this or have to do this. 50% of my step definitions have no parameters 
> at all, and I suspect less than 3% have more then one parameter.
>
> We don't criticize Ruby for allowing us to write stupid code, but it 
> seems that we expect Cucumber to do more.
>
>
>     But I find that I write very cucumber-ish rspec features.  I’ll
>     have a bit of “As a… I want to… In order to…” as the name of the
>     feature and then my scenario names will be a imperative style
>     “given…when…then…” describing what’s going on.  The actual body of
>     the scenario will be a bunch of very high-level method calls like
>     “login_as_a_whatever_user”, “create_a_blah”,
>     “search_for_something”, “check_that_widget_appears_in_the_place”.
>
>     I try to keep raw capybara calls out of the scenario body and only
>     use it in those methods.  I’m not totally strict about that, I
>     might allow myself a visit “/some/path” or click_on ‘some label’
>     as I think they’re pretty readable.  I also find that I’m not that
>     interested in reuse of these methods.  I might extract some common
>     helpers for dealing with login or dealing with common UI patterns,
>     but mostly the methods live at the bottom of the feature file
>     they’re used in.
>
>     I think this gives me the same thoughtfulness and readability of a
>     cucumber feature, but without the context switch of dealing with
>     gherkin, step_definitions and World(all the helpers).
>
>
>     On 25 July 2014 10:26, Joel Chippindale
>     <joel.chippindale at futurelearn.com
>     <mailto: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 <mailto: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
>
>
>
>     _______________________________________________
>     Chat mailing list
>     Chat at lists.lrug.org <mailto: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
>
>
>
>
> -- 
> ------------------------
> Andrew Premdas
> blog.andrew.premdas.org <http://blog.andrew.premdas.org>
> _______________________________________________
> 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
> Murray Steele <mailto:murray.steele at gmail.com>
> 25 July 2014 11:46
> I really liked that article because it matches how I write rspec 
> features :)
>
> I like cucumber because of how it makes me think about what the user 
> journey I’m testing is actually about and for, but I dislike cucumber 
> because I think the regexp matching for step definitions places an 
> unnecessary burden on the developer.
>
> But I find that I write very cucumber-ish rspec features.  I’ll have a 
> bit of “As a… I want to… In order to…” as the name of the feature and 
> then my scenario names will be a imperative style “given…when…then…” 
> describing what’s going on.  The actual body of the scenario will be a 
> bunch of very high-level method calls like “login_as_a_whatever_user”, 
> “create_a_blah”, “search_for_something”, 
> “check_that_widget_appears_in_the_place”.
>
> I try to keep raw capybara calls out of the scenario body and only use 
> it in those methods.  I’m not totally strict about that, I might allow 
> myself a visit “/some/path” or click_on ‘some label’ as I think 
> they’re pretty readable.  I also find that I’m not that interested in 
> reuse of these methods.  I might extract some common helpers for 
> dealing with login or dealing with common UI patterns, but mostly the 
> methods live at the bottom of the feature file they’re used in.
>
> I think this gives me the same thoughtfulness and readability of a 
> cucumber feature, but without the context switch of dealing with 
> gherkin, step_definitions and World(all the helpers).
>
>
>
> _______________________________________________
> 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


Office location: 20-24 Broadwick Street, London, United Kingdom, W1F 8HT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/ee06b415/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1257 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/ee06b415/attachment-0016.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1362 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/ee06b415/attachment-0017.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1298 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/ee06b415/attachment-0018.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/ee06b415/attachment-0019.jpg>


More information about the Chat mailing list