You know I might not be the most qualified person to talk about TDD. I may not be the best developer in the world with TDD, but I struggled with it for a long time and I want to help others get through the “Basics” with less pain than I went through learning TDD.
First Let’s talk a bit about TDD. We are going to hit the basic questions.
Who: Who can do Test Driven Development?
– Anyone. Everyone who programs can do test driven development since it is a type of development. A way to do development.
What: What is Test Driven Development?
– Good question. Test Driven Development is a type of development where you use your code before you write it. Yeah you read that right. You use your code before you write it. What this basically means is that you write a test for a piece of code before you actually write your code. This may seem odd, but once you get the hang of it TDD is quite powerful.
When: When do you use Test Driven Development?
– All the time. Again TDD is a way to develop software so it can be done anywhere on anything for the most part.
Where: Where do you use Test Driven Development?
– Everywhere. If you write code somewhere you can use TDD to help write it.
Why: Why would you use Test Driven Development?
– Ah, the 100 million dollar question. Why would you possibly want to do this. Well the answer is simple. Eventually you are going to need to use your code. At some point your code is going to be implemented and you want to make sure it works. So the best solution is to put forth a little for-thought and pre-implement your code. That way when you write your code you know when it is working.
How: How do you use Test Driven Development?
– Well we will get to that in the next few parts as this is a multi-part series.
Now these are some vague descriptions and answers. I did that on purpose for one key reason to make you think for a few minutes.
Let me just run you through some of my experience with Test Driven Development. At first it was plain hard to figure out what in the world was going on. It didn’t make any sense of why or how you can implement code you haven’t written yet or why you would. It still kind of boggles my mind. However, as I have used TDD more and more I have grown to like it A LOT. In some respects it is like a video game while using NUnit you write a test write enough code to get a compilation run the test hey it fails and is red. Now you plug away at that one piece of code until it is green.
I think the absolute greatest thing about TDD since I have started it and is why I am loving it is because I can completely restructure my code and as long as ever test passes I know my code is good. Also if I do break something I know where it is broken and where to begin to look. Think about it for a second. If you have say 10,000 lines of code and 90% of it has tests and you have to do some major refactoring or redesign you will know what breaks and where immediately instead of having to try and run the program to figure that out.
I just want to make one last point. I am still learning TDD and am still a junior developer. However, I have a passion for coding and passion to help other people not fall victim to learning stuff the hard way and the long way like I had for TDD.
Stay tuned for part 2.