<div dir="ltr">Yep, this article describes what I do, too. I started using steak [<a href="https://github.com/cavalle/steak">https://github.com/cavalle/steak</a>] 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.<div>
<br></div><div>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.</div>
<div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 July 2014 11:46, Murray Steele <span dir="ltr"><<a href="mailto:murray.steele@gmail.com" target="_blank">murray.steele@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px">I really liked that article because it matches how I write rspec features :)<div>
<br></div><div>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. </div>
<div><br></div><div>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”.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div></div><div style="font-family:arial,sans-serif;font-size:13px">
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On 25 July 2014 10:26, Joel Chippindale <span dir="ltr"><<a href="mailto:joel.chippindale@futurelearn.com" target="_blank">joel.chippindale@futurelearn.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">We recently blogged about how, at FutureLearn, we write readable feature tests with RSpec*, see <a href="https://about.futurelearn.com/blog/how-we-write-readable-feature-tests-with-rspec/" target="_blank">https://about.futurelearn.com/blog/how-we-write-readable-feature-tests-with-rspec/</a>, and it made me wonder how common this approach was.<div>
<br></div><div>Are any of you using this approach already? If so, how are you finding it?</div><div><br></div><div>J.<br><div><br></div><div><br></div><div>* Hat tip to the developers at Econsultancy who introduced me to this way of using RSpec.</div>
</div></div>
<br></div></div><div class="">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>