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

[Sidu Ponnappa]

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
>