When to TDD (Test Driven Develop), a Newbie’s Story

I just finished my Actualize coding bootcamp which culminated in a capstone project. After a while of struggling through my heavy backend code we learned about TDD (I know it’s Test-Driven Development, I was using the verb form in the tittle).

I was completely stuck on my capstone project when we had our TDD class. I had been coding for hours on the weekends completely in the weeds of huge Rails model methods and, of course, nothing was working. At first TDD looked like a pretty dumb way to do twice the work, but as we went through the dumb seeming exercises in class, it was as if the clouds parted and the angels started to sing, “Do this in your capstone…ah ah AH!”

Hopefully you have that image set squarely in your mind. In truth there are definite positives and negatives to TDD but for those of you out there who have no idea what TDD even is, this article is for you.

The Pro’s of TDD

I wont go into a lot of detail about what TDD is, and I only have real experience in Ruby on Rails using RSpec, but here are the basics. TDD is basically when you write the tests for the code before you start and then you code incrementally.

The idea is you write a test, starting as simple as possible, and write code to pass the test. Then you write another test, just a small step more complicated than the last, and write code to pass that test. As you go, you build out your tests just as you build out your code. You then have a permanent array of tests you can run every time you make a change in your code.

The main pro, is you write code that you know works and you catch your mistakes as you go. If I were to try and debug my code, I would have had to go through every element that could be the weak link and test it out. In my experience, the code I was most suspicious of was code that I hadn’t used before. It would take a lot of time and effort to debug my active record queries for example. Instead I rewrote my code using TDD and I was able to have much more confidence in those model methods.

The Cons of TDD

Though it was all worthwhile, I found that TDD worked great with methods that calculated some number or created/destroyed an object. It didn’t work as well recognizing dates or checking that specific routes worked. These were things that I probably could have figured out how to do in RSpec but they also weren’t hard to test just by doing them in the app and checking the result. They also weren’t the things that had been breaking before. In other words, there is a cost benefit analysis you have to do when deciding to use TDD. It does take a lot of work and there are many things that just aren’t worth it.

In the end, TDD really helped me to understand what my code was doing and made it more robust. I would recommend looking into it more, and trying it if you are stuck. I also wouldn’t recommend blindly implementing it just for fun, but that’s just me.