TDD best practices, tips and many more. New blog started!

Practice, practice, practice: from now on always start with test

Admit it. You don’t do TDD because you don’t know how.

This blog is about TDD for a developer who wants to start doing TDD. I assume that you are a developer with experience. I assume you have the basic knowledge of what TDD might be. I assume you are thinking of trying out TDD. That was my situation about 2 years ago. I was looking for a set of TDD best practices but found none. That is why I decided to write something that might get you faster to the point that I am in right now so that we can continue this journey together.

I am a Java developer. I have been one for over 4 years now. I work on fairly large applications. I am still on my journey of discovering the best practices I should follow.  Fortunately I met many good souls on the way and I am now confident that I can start calling myself a TDD developer. Now I know that TDD is not only about good code quality. It is a style of work, influences the whole process and at the end you are enjoying your work a lot more then you used to. Less frustration, less problems, less hassle.  There are many cases where TDD might not be a good idea, but in most cases it is fortunately.

I know some developers that don’t do TDD because they have been doing development for more then 10 or 20 years. They are very skilled and mostly work on their own, not in teams. This is one of the cases when this blog might not be that much useful.

Most of the code examples presented here will be in Java. The topics are not ordered in any way, I write what comes to my mind.

Can you help me?

My purpose in starting this blog is also self-education. I consider myself as a mid-level developer thus I seek feedback on my ideas all the time. I hope to enjoy discussions with you about the subjects that I will work on.

TDD is a skill one has to learn

I will not try to make you a TDD developer. But I will always advise just to try. Think of the new technologies you use sometimes. Once upon a time I tried using Ruby On Rails since it was said to be a fast way of getting an idea into production. It worked. Then I tried TDD, I wanted to enjoy my work even more. It worked. Now I work in a XP team, do TDD and pair programming on daily basis and enjoy the work and the salary 😉 It might be the same for you! Give it a try and see what happens.

TDD in legacy code

I would advise trying TDD on a new project. Doing TDD on legacy code that was not driven by tests from the beginning might lead to frustration when one lacks the knowledge of the common patterns that can be applied. On the other hand I did it with help of my fiends and it worked so I guess the decision is up to you.

Practice, practice, practice

Commit to practice each day. It worked for me. I had to deal with many obstacles along the way (legacy code not driven by tests, large team not willing to try TDD, …) but it was worth it.
Also, couple of the coolest things I learned came up during my own experiments at home with self-assigned programming exercises. Try to think of a problem and find a solution doing TDD!

Recommended video for today:

http://www.youtube.com/watch?v=XcT4yYu_TTs

Recommended book for today: (may be a bit out of date, but still a classic):

Test Driven Development: By Example