[LRUG] Writing readable feature tests with RSpec

[Sam Phillips]

Yep, this article describes what I do, too. I started using steak [
https://github.com/cavalle/steak] in the early days and then capybara
features directly, with a module with common helpers. The skill of this
approach is the same as with cukes - not writing shared helpers that are
too brittle, contain too much behaviour, or hide overly-greedy mocking.

In general, I find cucumber written for a very specific team setup (highly
technical PM/BA, team that are comfortable with muchos regexes) that rarely
exists. I've been using cucumber since it started and in that time, I've
only worked on one team, for a month or 2, that used it as designed. I
think the sentiment of recent talks on the subject, which as been along the
lines of "BDD is a practice, not about a tool", is good - but often the
next phrase is "... as long as BAs use cucumber". Let's face it, most BAs
and PMs are happier with MS Word.




On 25 July 2014 11:46, Murray Steele <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.
>
> 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>
> 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
>> 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
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140725/a3efb9d6/attachment-0003.html>