<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On 31 July 2014 22:31, Sam Livingston-Gray <span dir="ltr"><<a href="mailto:geeksam@gmail.com" target="_blank">geeksam@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 class="gmail_extra"><div class="gmail_quote"><div class="">On Thu, Jul 31, 2014 at 12:29 PM, 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"><br><div class="gmail_extra"><div class="gmail_quote"><div>On 30 July 2014 17:32, Sam Livingston-Gray <span dir="ltr"><<a href="mailto:geeksam@gmail.com" target="_blank">geeksam@gmail.com</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div>You might also find yourself wanting to separate out responsibilities by topic area, so that you wind up writing step code like:<br></div>
<div><br></div><div>step_driver.given.i_am_logged_in_as 'sales_rep'</div><div>step_driver.when.i_have_net_revenue '$20,000'</div><div>step_driver.when.commissions_are_calculated</div><div>step_driver.then.i_receive_payout_of '$5'</div>
</div></div></div></blockquote><div><br></div></div><div><div style="font-family:arial,sans-serif;font-size:13px">I don’t get the benefit of this; all that step_driver.[giv|[w|t]h]en seems sort of noisy. Why would you do that instead of just something like:</div>
<div style="font-family:arial,sans-serif;font-size:13px"><div> </div>i_am_logged_in_as 'sales_rep'<br><div><div class="gmail_extra"><div class="gmail_quote">i_have_net_revenue '$20,000'</div></div></div><div>
<br></div><div><div class="gmail_extra"><div class="gmail_quote"><div>calculate_commissions</div><div></div></div></div></div><div> </div>i_should_receive_payout_of '$5’</div></div></div></div></div></blockquote><div>
</div></div><div>Over the years, I've learned that the less of my code lives in Cucumber's domain, the happier I am. I view step definitions as a quick translation layer between Gherkin and a sensible Ruby API that I can refactor to suit my evolving needs.</div>
</div></div></div></blockquote><div><br></div><div>Agreed<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> In contrast, Ruby step definitions strongly resist refactoring, and pushing the problem out to a bunch of modules that all get included into World is only slightly better. </div></div></div></div></blockquote><div>
<br></div><div>No, World is one of the most misunderstood things about cucumber. I believe it was a concious design decision to make World a single global space. The idea of a single space is based on the understanding that viable applications have clearly stated non-ambigous concepts. One of the main points of writing features is to say what these concepts are and why they are important. Putting your Ruby API in the single World namespace imposes the discipline that in this single namespace you must be able to clearly differentiate each key concept by its name. It also requires that you limit the number of concepts and therefore the size of your API to something that is manageable. Both of these are highly desirable. Of course this API which the step definitions utilize can delegate further, but I'd question whether its wise to let this further delegation leak into the actual step definitions.<br>
<br></div><div>All best<br><br>Andrew<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Both situations feel a lot like PHP to me: everything is available in one global namespace, and I've found that that makes it very easy to wake up and find oneself in dependency hell.</div></div></div></div></blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Admittedly, you could probably get rid of the "step_driver" in my example and just define #given, #when, and #then methods directly on World; you could also drop the g/w/t versions and rely on your ability to name methods in a way that communicates whether they're arranging, acting, or asserting.</div>
<div><br></div><div>I actually wound up with a slightly different breakdown on a recent project; in that, my example would look more like:</div><div><br></div><div>step_driver.misc.log_in_with_role 'sales_rep'</div>
<div>step_driver.commissions_actual.assign_net_revenue '$20,000'</div><div>step_driver.commissions.calculate_for_current_month</div><div>step_driver.commissions.verify_payout '$5'</div><div class=""><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:13px"></div><div style="font-family:arial,sans-serif;font-size:13px">I admit, I’m not exactly clear on what problem Paul was originally describing, nor am I clear anymore if we’re talking about cucumber or rspec features.</div>
</div></div></div></div></blockquote><div><br></div></div><div>I've forgotten the problem as well, but code like this can be reused between cucumber or rspec if you're into that sort of thing. Or, at some point whoever's maintaining my app decides they really don't like Cucumber, it won't be completely out of the question for them to port the tests to their test/spec framework du jour.</div>
<div><br></div><div>I don't seriously anticipate either situation, but I do still occasionally work in an app that's stuck using an old version of Shoulda, which sucks—we've actually recreated our own version of RSpec's .let functionality to make those tests slightly less awful to write. So that concern isn't *completely* theoretical. :)</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:13px">
If we’re talking cucumber, then it doesn’t seem so awful as the actual step name is what we’ll see in the test so these extra objects and methods are not in the way. However, if we’re talking rspec features then I don’t understand the motivation for introducing the line noise as it reduces the readability of the spec.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I’m sure there’s a good reason and I’m just missing something.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div><span style="font-family:arial,sans-serif;font-size:13px">Forgive the use of the “should” in my re-write, but I couldn’t think of a better word to indicate that the final method is an assertion. Perhaps this is enough motivation for the noise?</span></div>
</div></div></div></div></blockquote></div></div></div></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>