[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.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.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-0001.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-0002.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-0003.jpg>
More information about the Chat
mailing list