Everything I know about introducing TDD in an org

Hopefully you’ve read part one of this series where I talk about why one should do TDD. Teaching TDD is kind of out of scope here but at some point I will compile a list of the best resources on the web to come up the curve. The rest of this article assumes that you, dear reader, have taken Part 1 to heart and devoted ample time to becoming fluent in TDD and are now looking to spread the sweetness and joy in your org. Or perhaps you joined a new org where they do not do TDD and you want to introduce it here. Good on you!

But my friend, you have a lot of work ahead of you. Introducing TDD in an org is no trivial task and I hope that you’re convinced about the benefits of TDD through your own experience. In order to do this, you will have to do the following.

• convince the leadership.

• convince the team

• choose a project to be the guinea pig.

• execute

• …

• profit

In this post I will talk you through the process of how to change the developer experience in your company so that projects finish with a minimum of stress. Yes, you know that phase of the project right at the end where every bug fix results in two new ones? We’re going to do away with that phase entirely!

Read on!