Understanding TDD Resistance – Is It More Than The Learning Curve?

30Sep08

I’ve been reading a lot interesting posts lately around Test-Driven Development adoption, or the lack thereof, the collective synopsis of which goes something like:

TDD is too difficult and cumbersome to gain widespread traction.  It needs to change if it is to get anymore mindshare among developers.

Roy Osherove makes a compelling argument that developers continue to shy away from TDD because of its apparent complexity, not just in learning unit testing, but also mocking and the idiosyncrasies of mock frameworks, and dealing with all the ancillary methodologies that get swept up in TDD’s wake (Dependency Injection, IoC, etc.).  And all of these concepts become (paraphrasing) a big barrier to entry for too many developers.

I agree that there is a lot of “stuff” to learn when wading into the waters of TDD, and just trying to take it all in can indeed be daunting for many.

But is it really just the learning curve?

I’ve been thinking a lot about the phenomenon of resistance from developers to TDD, and wondering if there isn’t more going on than just a steep learning curve.  No doubt, I’ve witnessed developer resistance firsthand, and yes… at one time I was not exactly sold on it myself. 

Fortunately, I’ve gotten to a place where I really like TDD.  Granted, I had the help of some extremely knowledgeable, supportive mentors who actively encouraged me to look for the benefits.  (Extra-strength caveat: I consider myself too new to TDD to be any kind of authority; I just appreciate its tenets and find myself happy enough exploring ways to incorporate Test-Driven practices into my daily coding life.)

But I have to say that the learning curve wasn’t what kept me away from TDD, and it hasn’t always been what I’ve heard from other developers.

The message to the developers

My perception is that Test-Driven Development has largely been promoted to developers as a very necessary evil: Yeah, there’s a lot to learn, but it’s good for you, so learn it.  Not everywhere, of course, and not by everyone I’ve ever heard speak about it.  But when the topic of TDD comes up the most common themes (or sometimes just the loudest voices) have been akin to…

"You need to be doing unit testing"

“And while you’re at it, you need to start writing your code so that it can be tested”

"You need to start mocking"

"And while you’re at it, you need to start designing your objects so that they can be mocked"

The intentions behind statements like these are actually well-meaning; the problem is not so much with the content but with the delivery.  Telling developers that they need to be applying some methodology, especially something completely new to them, implies that if they’re not doing so then… well, it’s a wonder how they’re getting anything done, or at least done correctly.  More often than not it creates resistance to the very thing they should be embracing.  And whenever someone is resistant to your message then invariably part, if not all, of it will get lost.

In my experience, the learning curve as a factor in low TDD uptake among developers might have been the most common excuse, but not necessarily the most accurate explanation.  The reality for me is that if TDD has a negative connotation it is mainly because too many times developers were told that they couldn’t be writing solid code without it.  And with that kind of association, a learning curve of any slope at all is going to be an easy target for avoidance.

Showing the positives

The best way I know to sell a methodology like TDD is to show how it can make things better.  I was shown time and time again how unit tests worked, and I always came back to the question of “now… why am I doing this again?”  Then one day I had refactored a huge chunk of code and, feeling very sure of myself that I hadn’t broken anything, ran my (all passing) tests only to discover “what the… a failure?!  No way!”  Sure enough, I had inadvertently introduced a bug that probably would have snuck all the way into QA had I not run those tests.  Thank you, Unit Tests!

I wasn’t drawn to unit testing until I could see for myself what no one else was really showing me: it helped me with my code.  My tests had sniffed out bugs that I had clearly missed… that I wouldn’t really even had thought to look for… and they did it within seconds.  I had to experience the benefit; only then did the methodology make sense.  From that point on, I enjoyed writing tests. 

Rather than asking TDD to change so more developers will appreciate and adopt it, I’d like to see TDD shown more for what it’s goals are: to make the code, and ultimately the deliverables, better.  (Not just different, because different by itself doesn’t mean anything.)  Emphasize the benefits that naturally manifest from Test-Driven practices (more robust code, fewer defects, etc.) and then negotiate the learning curve.

What has been your experience with Test-Driven Development, and how have you perceived its promotion within the community?  If you are already using TDD, how did you get there?  By mandate, desire, or accident?  Were there any problems along the way?  And if you are resistant to TDD, where is that resistance rooted?

Advertisements


2 Responses to “Understanding TDD Resistance – Is It More Than The Learning Curve?”

  1. 1 R. Eric Geiger

    TDD does indeed demand a strong grasp of OO principles, as both you and Jeremy point out. Those who aren’t up to that level in design will struggle if they’re jumping head-long into Test-Driven.But I would also add that, if developers are having trouble in the OO world to begin with, approaching TDD is the least of their worries. They would most certainly be having a host of other problems besides climbing that particular learning curve.And, no, I can’t think of any code offhand that would be “solid” but untestable. (That whisking sound you hear is NOT a bunch of old APIs being swept under the nearest rug) 🙂

  2. 2 J.P. Hamilton

    Jeremy Miller made the best comment on TDD that I have read in a long time. I think it really sums up the truth. Basically, he said that TDD “punishes” people who don’t understand coupling and cohesion. I will take that a step further and add “object-oriented programming and design principles”. I think TDD forces you to write good-ish code at the very minimum. If you are finding it hard to test then you are probably not writing code that is flexible, adaptable, or maintainable (i.e. some attributes I consider inherent in “good” code). If I am wrong about this, I would like someone to point me to code that they feel is well written that is still hard to test. I hear these claims, but I am not seeing code.



%d bloggers like this: