<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 August 2014 18:40, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Thu, Jul 31, 2014 at 3:00 PM, Andrew Premdas <span dir="ltr"><<a href="mailto:apremdas@gmail.com" target="_blank">apremdas@gmail.com</a>></span> wrote:<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 class="gmail_extra"><div class="gmail_quote">
<div><div class="">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>
</div><div class=""><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 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. <br></div></div></div></div></blockquote>
</div></div><div class="">
<div><div>
<br></div></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>
</div></div></div></div></div></blockquote><div><br></div><div>Very interesting, and thank you for a response I actually had to sit and think about for a day. :D</div><div><br></div><div>While I enthusiastically support the idea of a design decision that deliberately inflicts pain on those who stray from it (it's one of the things I love about MiniTest in theory, even if in practice I mostly use RSpec), I'd argue that having a global namespace for step definitions already accomplishes this. Making World a single global space as well just means that I have to maintain two translation layers instead of one, and I'm not convinced that that that second layer of global-ness adds enough value to justify its existence.</div>
</div></div></div></blockquote><div><br><div class="gmail_quote">World is the global namespace for step
definitions, put a debug statement in a step definition and look at
self, you will get something like<br><br>#<Cucumber::Rails::World ...<br><br></div>World is the place to create an api for step definition implementations to use. The next namespace up is main. I assume you're not thinking of this as the global namespace for step definitions. Perhaps you can think of things as two sorts of translations, but I see it as a translation followed by a call. So we have<br>
<br></div><div>Feature -> translate to -> step_definion -> implement by call to -> World api<br><br></div><div>Example:<br><br></div><div>Given I am signed in<br><br></div><div>tranlate to <br><br></div><div>Given "I am signed in" do<br>
</div><div> # implement by a call to World api<br></div><div> sign_in as: @i<br></div><div>end<br><br></div><div># Define World api<br></div><div>module SignInSH<br></div><div> def sign_in(attrs={})<br> ...<br></div>
<div> end<br></div><div>end<br></div><div>World SignInSH<br><br></div><div>Hopefully that shows that there isn't a second layer of global-ness, or a second translation layer<br><br></div><div>All best<br><br></div><div>
Andrew<br></div><div> <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 class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Related: I finally got around to open-sourcing a gem (still in 0.x territory) I've been extracting from an internal project. The README still lacks a good code example, but anyone brave enough to dive into the implementation might find it interesting: <a href="https://github.com/livingsocial/hypercuke" target="_blank">https://github.com/livingsocial/hypercuke</a></div>
</div></div></div>
</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>