<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="">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 class=""><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 class=""><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>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. 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. 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><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><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 class=""><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>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><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 class=""><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>