How I learned to stop worrying and love TDD

It’s almost unanimous in the articles and studies on the internet these days: Test-driven development (henceforth, TDD) is the way developers should be creating everything. But if you’re like me, getting started is a lot harder than it sounds.

Avoiding Testing

I was first introduced to TDD about six months ago, in The Odin Project’s Ruby course. I recognized the benefits at that time. It seemed like a clear “best practice” to adopt. Yet, due to a sense of overload I was feeling at that time, I skipped the TDD project and went straight to building the chess game, sans-TDD. I was happy to have “completed” the Ruby course so I could move on to learning Ruby on Rails.

When I got to the Rails course, one of the primary resources used was Michael Hartl’s excellent Rails Tutorial. This guide “takes a lightweight, intuitive approach to testing, employing TDD when convenient without being dogmatic about it” (chapter 3, section 3). This makes sense: while strict TDD seems like a good idea in a corporate environment, this pragmatic approach seems better suited to most web app development. This allows the developer to work a little faster while still building up good test coverage along the way.

Still, when it came to building my own apps, I found it difficult to implement even this lighter form of TDD. At first, I blamed it on the projects being too small. Some of them involved setting up just one or two models, maybe a single form. Writing tests didn’t even seem necessary since I could easily test all of that functionality manually.

When the projects got bigger (here and here), the excuse changed to a lack of time. Figuring out how to write the tests for each step might take as long as it took to build the app. I could certainly get through the project much more quickly if I didn’t bother with the testing. This was true — sort of.

The problem with not testing your code is obvious: it’s untested. Yes, you’ve run the app on the local server and tested to make sure the requirements have been met and you can navigate successfully through the app. But automated testing is about more than just that — it’s covering the edge cases and the scenarios you won’t typically run into when you’re just checking the basic functionality manually.

The tide turns

The final Rails project for The Odin Project (a Facebook clone) taught me another major downside of delaying testing. As you know if you’ve been reading my articles, I’m currently a student at Microverse. This means two things which are relevant at this point in the article: first, I am working with a programming partner (thus the use of the term we when discussing this project); second, testing is required on all of our projects. When we got to this project, we again (as we had on every project thus far) opted to delay testing until the app functionality was complete.

Yes, TDD takes more time up front, but the larger the project, the more time it saves you by the end.

The above chart (which you can find several versions of online) summarizes our experience working on this larger project. It was clear that by the end, we were spending too much time testing things manually and making sure that nothing broke when we made changes. If we had implemented testing as we built each new feature (even after the feature was complete), we could have significantly reduced our manual testing and saved a lot of time.

On top of the time wasted with manual testing, there was the fact that we still had to write the tests anyway, since a real application cannot (well, should not) be deployed without a test suite. By waiting until the end to write the tests, we missed out on the benefits of TDD but still had to spend the time writing the tests.

Testing in the real world

While the Facebook clone was our largest project in this course, production applications typically include many more models and features. As that feature list grows, TDD becomes even more important and valuable.

We were recently hired for our first freelance contract, working on a website that is already live. The value of a good test suite on a production application was immediately clear. Just making sure that each person on the team has the development environment set up correctly is much easier when good test coverage is in place. Then, tests need to be required for each new feature that is added in order to be confident that it is working correctly, and so others on the team can quickly verify that it works for them too.

You don’t want your users to see this error.

I think my experience with testing is typically among new developers. At first, testing seems to be a waste of time or a nice-to-have. Then we think of as a “necessary evil,” before finally realizing that it can save us a lot of time and agony when implemented correctly. Also, the more skilled and confident we become at writing tests, the more likely we are to use them as we should.

The conclusion, for all the new developers out there, is that you need to dive right into testing and TDD. Even if it seems silly to do it for small projects, getting into the habit right away will pay off when you start building and working with larger applications. Stop worrying about whether your app works, and love TDD.

How I learned to stop worrying and love TDD was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.