<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 July 2014 11:10, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div class="">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:</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 class=""><div>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><div class=""><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 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><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></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 class="">
<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><div><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><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></div></div></blockquote><div><br></div><div>I think its a little more subtle than that, and one of the reasons I prefer using Cucumber to RSpec for this sort of thing is that Cucumber makes the following a little more obvious.<br>
<br>When you are writing features you have two very seperate things that you are doing. The first is writing code that translates the meaning of a feature into a call that does something. The second thing is implementing calls that do something. As an example if we take something simple like signing in we might have<br>
<br></div><div>When I sign in<br></div><div>When Murray signs in<br></div><div>Given I am signed in<br></div><div>etc...<br><br></div><div>The mistake people make is to DRY up the translation. So in Cucumber they make one step definition with horrible regex's to implement this. However the only thing you need to dry up is the execution (the code that actually signs you in). So when I Cuke I'm quite happy to have<br>
<br></div><div>When I sign in do<br></div><div> sign_in as: @i<br><br></div><div>When Murray signs in<br></div><div> sign_in as: "Murray"<br><br></div><div>Given I am signed in<br></div><div> sign_in as: @i<br>
<br></div><div>... it really doesn't matter how many step definitions are like this<br></div><div><br></div><div>But there is only one sign_in helper method.<br><br></div><div>Using Cucumber 'properly' means thinking of step definitions as being strictly translators who make calls. With RSpec getting this differentiation is a little bit harder; each rspec feature ends up doing alot of different things.<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>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></div></div></blockquote><div><br></div><div>I think its harder to write good rspec features. RSpec is designed to write tests, and you have to jump through some hoops to make it do feature work. For experts in RSpec these hoops might seem to have a lower cognitive load than working with Cucumber, but I suspect that is as much not having expertise in Cucumber and having expertise in RSpec, than the objective suitability (if there can be such a thing) of each tool to do this job. <br>
<br></div><div>All best<br><br>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></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></div></div></blockquote><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>Cheers,</div><div><br></div><div>Murray</div></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></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>