[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