My most recent project was the Connect Four terminal game. You can check this out here if you want. This project was supposed to improve my TDD (Test-Driven Development) skills, as I had to write tests for every step. You can check this out here if you want. It was a loooong project, and in this article, I’m going to tell you why. The TDD Lessons Before the Project Before I got thrown into Connect Four, I had to go through a couple of lessons and exercises about TDD. These lessons were actually pretty interesting. They explained: How TDD works, What it’s used for, Its advantages and disadvantages. How TDD works, How TDD works, What it’s used for, What it’s used for, Its advantages and disadvantages. Its advantages and disadvantages. One thing I really liked is that The Odin Project doesn’t force us to use TDD, instead, it just teaches how it works in detail so we can decide for ourselves whether we want to use it or not. The principles of TDD were pretty clear to me from the start as The Odin Project explains them very clearly, and I was actually keen to try it out. But at the back of my mind, I was a bit worried that it might stretch the time spent on each project… and, well, I wasn’t exactly wrong. Starting the Project (And Why It Felt Hard at First) So, I finished all the necessary lessons and started working on Connect Four. At this stage in the Ruby course, the game itself wasn’t hard to implement. The problem was: I had to think about all the tests first before writing any actual code. It was hard to wrap my head around this in the beginning. I had to think about all the tests first before writing any actual code. I had to think about all the tests first before writing any actual code. It was hard to wrap my head around this in the beginning. It was hard to wrap my head around this in the beginning. Even now, as I’m writing this article while working on the Chess game, it’s still a bit hard to remember all the RSpec syntax. Anyway! I quickly realized that the most important part of the process actually happens at the very beginning when thinking of test names. That was the crucial moment when I had to figure out: What is this test going to check? What will the corresponding method actually do? What is this test going to check? What is this test going to check? What will the corresponding method actually do? What will the corresponding method actually do? Once I figured that out, I wrote the basic test of course, struggling with RSpec syntax for a long time. But then… BLINK - it’s green! Awesome. Now, I can move on to the next test and method. It took me some time I’d say around 3 weeks? Something like that. But I must admit, by the end of this project, I had a much better understanding of this whole TDD “magic”. The Moment It Clicked (Why TDD Is Worth It) I realized that my project was MUUUCH BETTER thought out. Less spaghetti code Shorter, well-structured methods Everything named properly Less spaghetti code Less spaghetti code Shorter, well-structured methods Shorter, well-structured methods Everything named properly Everything named properly On top of that, I noticed I wasn’t wasting another week fixing bugs or refactoring half my code because I didn’t plan it properly from the start. You know that moment when a tiny mistake messes up half your code, and you have to go back and rewrite a bunch of stuff? Yeah, that barely happened this time. Will I Keep Using TDD? Yes. I liked this project. I like TDD. And I’m definitely going to stick with it for my future projects. Less troubleshooting. Easier to understand the code when coming back later. Just write tests in plain English, and you instantly know what your program is supposed to do. It’s as simple as that. The hardest part of all this is definitely RSpec—it just takes time to get used to: Mocking What to mock When to mock Mocking What to mock When to mock But honestly? The only way to get better at this is to just keep practicing until it becomes second nature.
