[LRUG] TDD a waste of time? (was Re: [JOB] CTO and business partenership)

Thu May 17 05:54:24 PDT 2012

What have I done!!? LOL.

Ooops.

Actually, I'm pleased to have sparked the debate. Although, it sounds like there is little to debate - "Do your TDD until you realise that it's good for you, naughty boy!"
I'm in agreement so would someone please come join us and make it happen!

TEST NAZI WANTED - Big sticks and thumb screws will be provided.

Hit me 'til I test*.

Just noticed I should have run a spelling test on my subject line.
"partenership'??

*Please note - slapstick sado-masochism only please.

On 17 May 2012, at 13:28, Sidu Ponnappa wrote:

> It's hard to get used to TDD at first, especially with Cucumber and
> friends muddying the waters. I'd strongly recommend ignoring Cukes
> until you're comfortable test driving most of your code using RSpec,
> Minitest, whatever. Once you're confidently and comfortable test
> driving all your code, come back to BDD and you'll see it in a whole
> new light.
> 
> The thing is, TDD is a *way* of writing code in languages which have
> side effects, not a tool. I can't not TDD now - any new OO language I
> pick up, the first thing I'm looking for is a TDD library. It's also
> the reason I contribute to RSpec. Without good TDD libraries, I'm
> hamstrung.
> 
> Until you stick with the discipline of TDD and get to a point where
> you're *faster* with it than without, you will not see this value.
> Coverage and regression testing should be a side effect of TDD, with
> the main objective being writing better encapsulated, well designed
> and (consequently) easily understood code. I've written about this in
> greater detail at
> http://blog.c42.in/tdd-isnt-about-testing-its-about-design
> 
> There are two way that I know of to get over the initial slowness and
> uncertainty - dig in and be stubborn about it, or pair with someone
> who already has. I had the luxury of the latter route, and budgets
> permitting, I strongly recommend it.
> 
> Best,
> Sidu.
> http://c42.in
> http://twitter.com/ponnappa
> 
> On 17 May 2012 16:57, Chris Parsons <chris.p at rsons.org> wrote:
>> 
>> On 17 May 2012, at 10:29, Kevin Monk wrote:
>> 
>> Test coverage is err.... *sketchy*. I know this may be a heretical thing to say but in the early stages and with a really small team, 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.
>> 
>> 
>> [snip]
>> 
>> 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.
>> 
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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].
>> 
>> 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].
>> 
>> 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 :)
>> 
>> For example: I put together a simple Sinatra app the other day, which had one post which checked a username/password:
>> 
>>     get "/api/auth" do
>>       halt 401 unless params[:user] = 'foo' && params[:password] = 'secr3t'
>>       "OK"
>>     end
>> 
>> 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.
>> 
>> I should really write this up as a blog post. Feel free to disagree with any of it :)
>> 
>> Chris
>> 
>> [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).
>> [2] http://destroyallsoftware.com
>> 
>> --
>> Chris Parsons
>> chris.p at rsons.org
>> http://twitter.com/chrismdp
>> http://pa.rsons.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org

Kevin Monk
Technical Director

Mango Swiss Ltd
Westow Hill Studios
45 Westow Hill
Upper Norwood
London SE19 1TS

E: kevin at mangoswiss.com
T: 020 8670 5461
M: 07736 066408