[LRUG] Writing readable feature tests with RSpec

Will william at theappbusiness.com
Mon Jul 28 07:15:06 PDT 2014


Completely agree with most of those points, Graham. Writing scenarios in 
isolation & skipping 'discovery' is not a good idea....and removes the 
benefits of BDD. If writing scenarios isn't adding any value, and it's 
much easier to use other formats....of course that's a no-brainer.

The one part I don't think I follow is why tests written with cucumber 
are necessarily difficult to refactor. As already mentioned, your 
cucumber tests can just be 99% pure ruby code much like tests you write 
with any other framework. Why do you not consider cucumber a 'proper' 
testing framework?

I also (incidentally) agree that the 'As a...I want to..' format isn't 
the only way to write user stories. I've seen a lot of people go into 
robot mode and churn out stories in that format for the sake of it; a 
recommended read that touches on this is Gozko Adzic's book '50 quick 
ideas to improve your user stories' https://leanpub.com/50quickideas

Whatever the testing framework used, I'd definitely recommend going 
through the steps of capturing user stories/backlog items, refining 
through conversations and analysis, agreeing a specification 
collaboratively & testing against that specification. I think it's 
possible to use cucumber for that last step, RSpec, other frameworks, or 
to test manually. Like you say, many ways to skin a cat....


Will

> Graham Ashton <mailto:graham at effectif.com>
> 28 July 2014 14:26
>
> I saw Liz Keogh give a talk at at Nordevcon this year, entitled “10 
> years of Doing Behaviour-Driven Development All Wrong”.
>
> She (along with Dan North) was one of the core developers of jBehave, 
> which is where the ideas that lead to Gherkin and Cucumber first saw 
> the light of day.
>
> Liz told us that she and Dan both came (independently) to the same 
> conclusion relatively recently: Writing scenarios is useful, but 
> automating them is a big mistake.
>
> That’s quite a statement.
>
> The point of writing scenarios was to enable “discovery”. To drive 
> conversations with stakeholders that would uncover what a product 
> really ought to do, and to do it early before time is spent committing 
> to your ideas in code.
>
> With Cucumber, what they’ve observed in the wild is developers sitting 
> down and writing Gherkin in relative isolation. By writing scenarios 
> on their own, Liz has observed developers to be:
>
> 1. Skipping the discovery step, and writing scenarios that don’t 
> reflect the actual requirements.
>
> 2. Committing to these mistakes early (code is a commitment).
>
> 3. Using a framework that makes it particularly difficult to refactor 
> that code later (i.e. automating Gherkin is a bigger commitment to a 
> bad plan than writing conventional tests would have been).
>
> 4. Confident (falsely) that they’re solving the right problem, because 
> they’re using BDD.
>
> In other words (these are direct quotes) “BDD is building software 
> that matters” and “Gherkin is the worst thing to happen to BDD”.
>
> My notes also contain the telling line “BDD gave people the illusion 
> that you could specify everything with scenarios”.
>
> In this talk Liz provided the first feasible explanation for something 
> that has had me nonplussed for years: Why did so many bright people, 
> for whom I have a lot of respect, continue to use and promote 
> Cucumber, while I found it to be an utter waste of time (and therefore 
> money)?
>
> Maybe scenarios gave them confidence that they were solving the right 
> problem, a feeling that they’d otherwise been missing?
>
> I do my “discovery" long before I get near an editor. I sit down with 
> stakeholders, sketch things on paper, ask lots of questions and do 
> everything I can to find out where their expectations don’t tally with 
> mine. Then I write story cards (not in the limiting “As a potato...” 
> form - in proper English, like a grown up) that describe *why* we’re 
> building what we’re building. I if I can’t explain the why, I haven’t 
> asked enough questions.
>
> If I were to sit down and write scenarios having had those 
> conversations, they’d have nothing left to teach me. Scenarios and 
> Cucumber consequently feel like dead weight *to me*.
>
> If you don’t enjoy working the way I’ve just described I can imagine 
> that writing scenarios could be a useful way to trigger discussions 
> that would save a lot of time. Once you’ve had those discussions, 
> there’s no reason to waste time using them as a basis for integration 
> tests - I feel that job is better left to a proper testing framework.
>
> The only solid conclusion I can draw from all these differing opinions 
> is that there’s more than one way to skin a cat!
>
>
> Anthony Green <mailto:anthony.charles.green at gmail.com>
> 28 July 2014 10:27
> The moment you think of Cucumber as a programming tool rather than a 
> mind hack you're deep into the weeds.
>
> Cultural transference is analogue and copying is lossy. 'TDD/BDD: 
> That's Not What We Meant'
>
> Later arrivals have mainly tertiary sources.
>
> Early adopters at the cultural core of BDD today push forward into new 
> areas. Dan North with 'accelerated agile' Liz Keogh and Chris Matts 
> with 'Cynefin'.
>
>
>
>
>
>
>
>
> _______________________________________________
> 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
> 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


*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/dc91b1e8/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1105 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140728/dc91b1e8/attachment-0020.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/20140728/dc91b1e8/attachment-0021.jpg>
-------------- 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/dc91b1e8/attachment-0022.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/dc91b1e8/attachment-0023.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/dc91b1e8/attachment-0024.jpg>


More information about the Chat mailing list