<div class="gmail_quote">On 17 May 2012 12:27, Chris Parsons <span dir="ltr"><<a href="mailto:chris.p@rsons.org" target="_blank">chris.p@rsons.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>On 17 May 2012, at 10:29, Kevin Monk wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
Test coverage is err.... *sketchy*. I know this may be a heretical thing to say but in the early stages and with a <i>really small team,</i> the TDD and BDD were interrupting the process of discovery and creativity when in early development. We use Cucumber and RSpec but for our initial purposes build came before test and we've been burnt before from an over enthusiastic test coverage whilst the B in the BDD was still being hammered out.</div>
</span></blockquote><div><br></div><div>[snip]</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
Having said all that, this is not a recalcitrant position. The product needs more test coverage now that it's rolling out as a Beta; partly for the reason that we need some regression testing. You may wish to consider this a technical challenge of the job. I'd genuinely welcome a dev that will teach me the error of my ways and I'd be more than happy to bask in the warm glow shining out of a GOOS TDD arse. It's cold out here. Show me how TDD can make my life better.</div>
</span></blockquote></div><div><br></div>OT to the original post, but I've seen this (quite understandable) argument a few times now in a few places, and thought it's about time I shared my point of view.<div><br>
</div><div>I can totally understand the position: I'm running a startup myself, and it's very painful when developers are wheel-spinning maintaining detailed tests for features that might not last a week anyway. Many people give up on TDD and BDD because they find it too hard, or they're spending too much time changing tests.</div>
<div><br></div><div>However, I just don't believe testing needs to be abandoned at any stage of the development. Often it's not testing that's at fault, but the tests we write.</div><div><br></div><div>Firstly, Cucumber works best as a communication tool, not a testing tool. It's strength is in ensuring that people who don't read code can understand what our app is doing. Avoid all those gems that try and write highly reusable steps using regular expressions. They're not worth it. Regular expression aren't much fun to code in, and it's hard to trace code execution. If we use Cucumber, let's write small scenarios perhaps a few lines long. Avoid backgrounds. Don't reuse steps much. Write really short step definitions, calling into well factored shared module code to do the work, with methods like 'create_user', 'sign_in_to_app'. If we don't, our cukes will become difficult and extremely time-consuming to maintain very quickly [1].</div>
<div><br></div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>Cucumber is so often misused and misunderstood. You can keep things very simple and do a tremendous amount with it. Following the advice above is a really good start. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Secondly, let's get good enough at TDD that we go faster if we write tests. This means practicing writing better tests and practicing refactoring. We need to learn how to spot duplication (*really* spotting duplication, of concepts not just code is really hard) and run our tests as often as we can (ideally several times a minute). We need to improve our tools and code so that our tests take no time to run (ideally under a second). We need to be prepared to go slower at first, but I believe it's worth it. Destroy All Software is a great resource for learning how to do TDD well [2].</div>
<div><br></div><div>Thirdly, we don't need to write tests when we don't need to (but we need make sure that you *really* don't need to - do step 2 first :) </div><div><br></div><div>For example: I put together a simple Sinatra app the other day, which had one post which checked a username/password:</div>
<div><br></div><div>    get "/api/auth" do</div><div>      halt 401 unless params[:user] = 'foo' && params[:password] = 'secr3t'</div><div>      "OK"</div><div>    end</div><div>
<br></div><div>I did not write a test for this (shock! horror!): I instead tested it via two curl commands. I did what I needed it to; so left it alone for a few hours. When I came to add Warden authentication in (which I barely understood at the time) you bet I wrote tests. Test where the risk is: would you bet your entire reputation on the code working or not? If not, write tests.</div>
<div><br></div><div>I should really write this up as a blog post. Feel free to disagree with any of it :)</div><div><br></div><div>Chris</div><div><br></div><div>[1] Plug: I'm talking about this at ScotRuby if you want to hear more (and probably running the cucumber course I do for the BBC publicly in the summer, too, if I can pull my finger out).</div>
<div>[2] <a href="http://destroyallsoftware.com" target="_blank">http://destroyallsoftware.com</a></div><div><div><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">--<br>
Chris Parsons<br><a href="mailto:chris.p@rsons.org" target="_blank">chris.p@rsons.org</a><br><a href="http://twitter.com/chrismdp" target="_blank">http://twitter.com/chrismdp</a><br><a href="http://pa.rsons.org" target="_blank">http://pa.rsons.org</a><br>
<br><br><br></span>
</div>
<br></div></div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<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"><div><br></div>-- <br><div>------------------------</div>Andrew Premdas<div><a href="http://blog.andrew.premdas.org" target="_blank">blog.andrew.premdas.org</a></div><br>