<div dir="ltr"><br><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></blockquote><div><br><div>This is really unfortunate. The fact that regex's are there in
Cucumber means that you 'can' do all sorts of stupid things with them.
If you do that will be a burden. However it doesn't mean you should do
this or have to do this. 50% of my step definitions have no parameters
at all, and I suspect less than 3% have more then one parameter. <br>
<br></div>We don't criticize Ruby for allowing us to write stupid code, but it seems that we expect Cucumber to do more.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px">
<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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><br clear="all"><br>-- <br><div>------------------------</div>Andrew Premdas<div><a href="http://blog.andrew.premdas.org" target="_blank">blog.andrew.premdas.org</a></div>
</div></div>