[LRUG] Writing readable feature tests with RSpec

Will william at theappbusiness.com
Mon Jul 28 01:39:42 PDT 2014 

Thanks, Tom....didn't know that, good to know :-)

> Tom Stuart <mailto:tom at codon.com>
> 28 July 2014 09:30
>
> To clarify, the `feature`/`scenario` syntax (actually just aliases for 
> `describe`/`it`) is a feature of Capybara: 
> https://github.com/jnicklas/capybara/blob/304e2fb/lib/capybara/rspec/features.rb#L11-L12
>
> What rspec-rails calls “feature specs” are vanilla RSpec example 
> groups with standard Rails spec helpers and Capybara setup included. 
> If you don’t want to use Capybara (or indeed Rails), there’s no reason 
> to use feature specs (or indeed rspec-rails) at all.
>
> If all you want is to be able to write `feature`/`scenario` instead of 
> `describe`/`it`, just put `config.alias_example_group_to :feature` and 
> `config.alias_example_to :scenario` in your spec_helper.
>
> (Or use Cucumber! :D)
>
> Cheers,
> -Tom
> _______________________________________________
> 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
> Will <mailto:william at theappbusiness.com>
> 26 July 2014 15:51
> 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


*Will Thomas
*
Senior Engineer

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
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/20140728/1c9a3964/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1251 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140728/1c9a3964/attachment-0016.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1156 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140728/1c9a3964/attachment-0017.jpg>
-------------- 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/20140728/1c9a3964/attachment-0018.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/20140728/1c9a3964/attachment-0019.jpg>

More information about the Chat mailing list