Why is Test Driven Development So Good

Article: https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

Last class, we got some hands-on experience with using Test Driven Development. These concepts always feel more concrete and understandable when actually working with them  yourself, rather than only reading articles or looking at examples. I’ve since gotten the hang of this method of development, and wanted to look into how it compares with other development strategies. Such is how I found Test Driven Development is the best thing that has happened to software design by Arek Torczuk.

Throughout the entire article, Torczuk compares the methodologies of code-driven tests and test-driven code. In other words, he judges whether code-first test later is better than test-now code later, respectively. The results for this vary, of course; some companies or teams may benefit more from one strategy than the other. A noted flaw of code-driven testing is that your tests do not challenge the implementation and design of your code. You can create all the tests you’d like on a specific method, but nothing would make you second-guess the way you wrote the method. 

This is where the test-driven approach would come into play. Having already written the tests, you have a better idea of what your code should look like, and how it should act. As Torczuk states, you can ask yourself “What do I expect from the code?” with writing tests before the method (Torczuk). Essentially, with TDD, you know all the answers to your questions and when enough is enough in terms of tests & code. In my mind, it makes the process more streamlined.

Another important part of TDD Torczuk mentions is that it gives quick feedback about the design of your software. You’ll sooner realize the potential issues with your existing codebase, and how it might affect your ability to add new functionality. 

I selected this article because test-driven development piqued my interest after I had more time to experiment with it. This article grabbed my attention specifically because it didn’t just reiterate the concept of Test Driven Development over and over. Another quite useful part of this article is its inclusion of real examples of TDD by the author.

The content of this article was clear cut and organized, and even though it may not have been a ton of new information, it was a different perspective comparing test-driven development and code-driven tests. I learned that generally TDD is more effective at producing well-implemented code than simply writing the method first and tests later. Seeing as we are continuing to learn TDD, I’m confident that I’ll be able to use this in my future projects/jobs if necessary. Or, I could suggest it to my team if we are struggling with writing tests after code.