[LRUG] Writing readable feature tests with RSpec

Sam Livingston-Gray geeksam at gmail.com
Fri Aug 1 10:40:31 PDT 2014


On Thu, Jul 31, 2014 at 3:00 PM, Andrew Premdas <apremdas at gmail.com> wrote:

> On 31 July 2014 22:31, Sam Livingston-Gray <geeksam at gmail.com> wrote:
>
>>  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.
>>
>
> 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.
>

Very interesting, and thank you for a response I actually had to sit and
think about for a day.  :D

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.

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:
https://github.com/livingsocial/hypercuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140801/d4d0cbab/attachment.html>


More information about the Chat mailing list