It seems that everywhere you read you will find blog posts asserting that it is difficult to convince others to use TDD, and that everyone talking about TDD is already a believer preaching to other believers. So what's the best way convince others?
I recently convinced a good buddy of me to starting doing TDD in his web development. It took a while, but finally he "saw the light." He tried to relay the information to his coworker, and his coworker didn't react as positively, citing the common "I don't want to waste time writing test code when I know my stuff works."
There are many many MANY hurdles of overcome to begin writing software using TDD. I won't go into great detail since you can easily find relevant posts on the web, but basically, if you have successfully transitioned to TDD that also implies that you have in one way or another adopted S.O.L.I.D. principles in software design.
The reason I say this is because it is literally impossible to do TDD otherwise. It is just plain painful. I've been there. It is so painful you shout in your head WTF are people thinking, how does this make my job easier?!
Usually when this happens, you'll probably notice that most (or all) of the SOLID principles have been violated one way or another.
<sarcasm>
Notice that even though this post was supposed to be about how to advocate TDD, I ended up talking about SOLID instead for a bit. What am I trying to get at?
TDD spans from the individual to the team to the organization. You need to be able to tackle it from all points of view. The obsession of the word 'test' has hurt TDD quite a bit. Anyone who's spent any reasonable amount of time will assert that tests are just a means to drive the design. Tests should read like a story (well to programmer eyes), and yes, I said read, as in readable!
At the individual level, you must convince them it forces you to design better code, because testing against badly designed code is not worth the pain/annoyance. You must assert that better designed code is good because it also means being more maintainable and less bugs.
At the team level, you must convince that collective code ownership is a good thing. There should never be a situation where "Bob's on vacation, we'll need to put a hold on Project A because only he knows it". Tests serve as a way on how to interact with a specific service, and are a jump-start to figuring out how to actually use a particular service. Moreover, collective code ownership is a means of sharing and distributing knowledge.
At the organizational level, you must convince managers that you are a professional software developer, and that it is your job to produce high quality work. And if what is required to produce high quality work involves writing proper unit tests, following SOLID principles, and even other agile practices like pair programming, then you should be allowed (and optimally encouraged) to do so. Now TDD might not work for everyone, or every organization, but I think everyone owes it to themselves to give it a fair chance.
I recently convinced a good buddy of me to starting doing TDD in his web development. It took a while, but finally he "saw the light." He tried to relay the information to his coworker, and his coworker didn't react as positively, citing the common "I don't want to waste time writing test code when I know my stuff works."
There are many many MANY hurdles of overcome to begin writing software using TDD. I won't go into great detail since you can easily find relevant posts on the web, but basically, if you have successfully transitioned to TDD that also implies that you have in one way or another adopted S.O.L.I.D. principles in software design.
The reason I say this is because it is literally impossible to do TDD otherwise. It is just plain painful. I've been there. It is so painful you shout in your head WTF are people thinking, how does this make my job easier?!
Usually when this happens, you'll probably notice that most (or all) of the SOLID principles have been violated one way or another.
<sarcasm>
- Single Responsibility Principle
- You mean 1 class to rule them all right?
- Open Closed Principle
- Does this have something to do with sockets?
- Liskov Substitution Principle
- I thought the point of Object Oriented Programming is that everything is an object!
- Interface Segregation Principle
- What's an interface?
- Dependency Inversion Principle
- I don't get it...I only have 1 super object anyway, I don't have dependencies.
Notice that even though this post was supposed to be about how to advocate TDD, I ended up talking about SOLID instead for a bit. What am I trying to get at?
TDD spans from the individual to the team to the organization. You need to be able to tackle it from all points of view. The obsession of the word 'test' has hurt TDD quite a bit. Anyone who's spent any reasonable amount of time will assert that tests are just a means to drive the design. Tests should read like a story (well to programmer eyes), and yes, I said read, as in readable!
At the individual level, you must convince them it forces you to design better code, because testing against badly designed code is not worth the pain/annoyance. You must assert that better designed code is good because it also means being more maintainable and less bugs.
At the team level, you must convince that collective code ownership is a good thing. There should never be a situation where "Bob's on vacation, we'll need to put a hold on Project A because only he knows it". Tests serve as a way on how to interact with a specific service, and are a jump-start to figuring out how to actually use a particular service. Moreover, collective code ownership is a means of sharing and distributing knowledge.
At the organizational level, you must convince managers that you are a professional software developer, and that it is your job to produce high quality work. And if what is required to produce high quality work involves writing proper unit tests, following SOLID principles, and even other agile practices like pair programming, then you should be allowed (and optimally encouraged) to do so. Now TDD might not work for everyone, or every organization, but I think everyone owes it to themselves to give it a fair chance.