<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 25, 2014 at 4:11 AM, Tom Stuart <span dir="ltr"><<a href="mailto:tom@codon.com" target="_blank">tom@codon.com</a>></span> wrote:<br><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>On 25 Jul 2014, at 11:41, Najaf Ali <<a href="mailto:ali@happybearsoftware.com" target="_blank">ali@happybearsoftware.com</a>> wrote:<br>
> /switches on Tom Stuart bat signal<br>
<br>
</div>:-)<br></blockquote><div><br></div><div>Does responding to this make me Robin to Tom's Batman?  If so, so be it.  (Tom, you may send me a cape and mask at your leisure.)</div><div><br></div><div>I just read Joel's blog post at the top of this thread.  Ironically, the same solution that the post suggests for RSpec also works perfectly well in Cucumber.  In fact, that approach is probably the only way to maintain any sort of sanity in Cucumber.  It's also recommended in <a href="http://pragprog.com/book/hwcuc/the-cucumber-book" target="_blank">http://pragprog.com/book/hwcuc/the-cucumber-book</a>, but if anything I think that book doesn't quite go far enough.</div>

<div><br></div><div>One of the fundamental problems with Cucumber, I think, is that so many people come away from our introduction to Cucumber thinking that because Cucumber is implemented by attaching blocks to regular expressions, *that's the only tool we have to organize the implementation of our step definitions*.  I'm definitely included in that statement:  it took me years to get to the point where the majority of my step definitions are one-liners that call out into some other layer of software.</div>

<div><br></div><div>Obviously, "add another layer!" is unlikely to appeal to those who think Cucumber already adds too many, but as with all technologies, there are tradeoffs involved.  On the one hand, Cucumber is necessarily a bit further removed from your code, which adds implementation costs.  On the other hand, that is *exactly the point* of using Cucumber!  As Tom so aptly said, it's a mind hack.  The benefit (IMO) is that Cucumber offers you a different way of thinking about the behavior of your system.</div>
<div><br></div><div>In some cases, the benefit may not outweigh the costs—but I humbly suggest taking a closer look at both, because while it's very easy to make a huge mess with Cucumber, it's also possible for diligent developers to minimize its implementation costs.  And I see significant benefits to the Gherkin DSL, especially, that make it seem like the baby that gets thrown out with Cucumber's bathwater.</div>
<div><br></div><div>Another factor may be that Cucumber offers several different kinds of benefits at different levels of an organization and on different time scales, but those benefits only outweigh the costs *in aggregate* and over time, making it too easy to fixate on a single aspect and decide "it's just not worth the bother."  Curious readers should refer to <a href="http://rubyrogues.com/077-rr-complexity-with-glenn-vanderburg/">http://rubyrogues.com/077-rr-complexity-with-glenn-vanderburg/</a>.  There's no #bookmark to it, so you'll have to search for where Glenn says "Somebody mentioned unit testing" and read the following two paragraphs.</div>
<div><br></div><div>Anyway, back to work.  (I hope to have considerably more to say on this topic soon.)</div><div><br></div><div>-Sam</div></div></div></div>