<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On 26 July 2014 01:24, Andrew Premdas <span dir="ltr"><<a href="mailto:apremdas@gmail.com" target="_blank">apremdas@gmail.com</a>></span> wrote:<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 class="">On 25 July 2014 11:46, Murray Steele <span dir="ltr"><<a href="mailto:murray.steele@gmail.com" target="_blank">murray.steele@gmail.com</a>></span> wrote:</div>
<div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px">
<div>I like cucumber because of how it makes me think about what the user journey I’m testing is actually about and for, but I dislike cucumber because I think the regexp matching for step definitions places an unnecessary burden on the developer.  </div>

</div></div></blockquote></div><div><br><div class=""><div>This is really unfortunate. The fact that regex's are there in 
Cucumber means that you 'can' do all sorts of stupid things with them. 
If you do that will be a burden. However it doesn't mean you should do 
this or have to do this. 50% of my step definitions have no parameters 
at all, and I suspect less than 3% have more then one parameter. <br></div></div></div></div></div></div></blockquote><div><br></div><div>To be fair to cucumber this is how I ended up using cucumber in my last outings with it and it was much nicer to use.  I learned a lot about how to write acceptance/integration specs from doing cucumber the right way.</div>
<div><br></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><div class=""><div></div>We don't criticize Ruby for allowing us to write stupid code, but it seems that we expect Cucumber to do more.<br></div></div></div></div></div></blockquote><div><br></div><div>Sure.  I think a large part of the problem here is that well written application code exhibits different qualities than well-written test code.  For example duplication is usually bad in application code as it means a bug can surface in multiple places but only be fixed in one.  However in test-code lots of DRYing up can make the tests harder to read and for me readability of tests is one of the most important qualities.</div>
<div><br></div><div>For all the different ways we can write bad cucumber, we can do the same things with rspec features.  The fact that we’re even writing articles about how to write rspec features in a (to me at least) clearer style suggests that there are plenty of rspec features out there written in styles that aren’t so useful.</div>
<div><br></div><div>I think well written cucumber is a good tool, and I’d rather have well written cucumber on a project than badly written rspec features.  All else being equal though, I’ll reach for rspec features.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Murray</div></div></div></div>