DEV Community

loading...

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

jhiatt profile image jhiatt ・3 min read

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.

Discussion (6)

pic
Editor guide
Collapse
ratraze_54 profile image
ratraze

It's also a good idea to use TDD to embrace "Program an interface, not an implementation".
It will also allow you to generate code from your tests, because almost all IDE's will mark your methods as absent, and you can generate them freely.

These concepts will help to design your code before you write any implementation whatsoever, and help you keep code away from bloating.

Collapse
jhiatt profile image
jhiatt Author

That makes sense. TDD forces you to be forward thinking so it can be a great way to push you to plan ahead.

I need to learn more about this "Program an interface, not an implementation" thing. Have any good suggested readings?

Collapse
ratraze_54 profile image
ratraze • Edited

I think this answer on quora can be helpful.

To continue with this topic I'll suggest reading Design Patterns or something from Gang of Four.

Thread Thread
jhiatt profile image
jhiatt Author

Thanks! I'll check it out.

Collapse
dev3l profile image
Justin Beall

TDD turns programming into a team sport! Think basketball instead of golf.

If an entire team practices TDD, pick any random person at any random time. A minute ago, all their code worked!!!

Collapse
jhiatt profile image
jhiatt Author

I love this point of view. It's probably much easier to write up some solid tests than explain in detail everything you are doing so that no one messes up your work. If someone changes something that affects your code, the tests will point it out for them. Just started a new project where TDD is not in place and we are feeling the effects.