Roy Osherove is one of my favorite .NET personalities. Having had the chance to spend some time with him in Seattle this past April at the Alt.NET conference I came to see him as someone who is very well thought out on many of his positions. Roy posted this last weekend a post on mocks and stubs that resonated with me. The premise of the article is that the learning curve to write tests is too great:
One of the main reasons most developers still today don’t really take to unit testing (and TDD) is the really high learning curve that is forced upon them. That is not to say that learning about
mocks, stubs, dependency injection, IoC containers, Extract & override technique, Record\Replay, AAA and more
-- is not useful, but it is a big obstacle to get people into the habit of doing something which they know is good for them – test their code, verify their assumptions, automate, integrate, be confident, get feedback, define behavior – all those and many other benefits are being thrown away by developers all over the world because the entry fee to this world is too high, for all the wrong reasons.
Jimmy Bogard, who's been on a bit of a TDD kick lately, wrote a post giving ten tips to maximize the return on TDD, #6 on the list:
Get everyone on board. Quality needs to be important to your team, as should be good design. Accepting less is a team decision, but that decision needs to keep in mind the cost of technical debt. One person can subvert an entire team's intention to start TDD, and it's up to the team leader to ensure that everyone moves together. If a team member refuses to cooperate, then it may be time to escalate the issue to HR. A team's success is more important than one team member's ego.
These two seem to be somewhat at odds. Jimmy is absolutely correct, everyone should be on board, but the fact is that getting them on board is difficult due to the learning curve (to Roy's point). When talking TDD it is easy to quickly bring up SoC, DRY, SRP, IoC, DI, and a myriad of other acronyms, each of which your team will have varying degrees of understanding of.
Currently on my team I'm bringing some of these ideas to my team. Some seems to stick while others seems to be tougher to grasp
Here's the question I have for you, dear reader. If you are new to TDD and seem to have "gotten it", what was it that made it all come together for you? If you are struggling with TDD what seems to be the thing that isn't clear? Are there certain concepts that you have found valuable to know to aid your learning? Are there other concepts/principles that while good intentioned, only muddied the waters for you when it came to testing and TDD?
In general I believe that as much as we are different many of us are the same. Where one struggles my guess is that many struggle. In my very first blog post on the devlicious site I stated:
Therefore as I engage you I ask that you engage back by leaving comments, emailing me, ect. The goal for me is to ultimately provide useful content to you and improve myself in the process.
I believe that if we can get to the heart of the confusion and break down some barriers we can flatten the learning curve. That isn't to suggest we dumb down TDD or cheapen it by turning it into something else, but rather through our collective experiences come up with a pathway through which the "zen" of TDD is understood for all who desire to learn.