My latest project was the Connect Four Terminal game. You can check it here if you want. This project was supposed to improve the TDD skills (the development dependent on the test), as it had to write tests for each step.
It was a Looong project, and in this article, I will tell you why.
TDD lessons before the project
Before I was thrown into the Connect Four, I had to go through lessons and exercises around TDD.
These lessons were actually very interesting. They explained:
One thing I really liked is that the ODIN project does not force us to use TDD, instead, it only knows how it works in detail so that we can determine whether we want to use it or not.
TDD principles were very clear to me from the beginning, as the ODIN project explained it very clearly, and I was already keen on his experience.
But in the back of my mind, I was somewhat worried that it might extend the time spent in every project … and also, I was not completely wrong.
The project started (and why did you feel hard at first)
So, I finished all the necessary lessons and started working on Connect Four.
At this stage of the Ruby cycle, it was not difficult to implement the game itself.
The problem was:
To date, while writing this article while working on chess, it is still a bit difficult to remember all the construction of the rsc.
anyway! I quickly realized that the most important part of the process already occurs at the beginning when thinking about the test names.
That was the decisive moment when I had to know:
-
What is this test for verification?
-
What will the method already do?
Once I discovered this, I wrote the primary test of course, as it struggled with the construction of the RSPEC for a long time.
But then … flashing – it’s green!
amazing. Now, I can move to the following test and method.
It took some time I will say about 3 weeks? Something like that.
But I must admit, by the end of this project, I had a much better understanding of this “magic” all of TDD.
The moment I clicked (Why is TDD worth that)
I realized that my project was the best thinking.
-
Spaghetti code is lower
-
Larst and organized methods
-
Everything is called correctly
Moreover, I noticed that I was not lost another week in repairing errors or re -creating half of the code because I did not plan it properly from the beginning.
You know that moment when it spoils a small half of your code, and you have to return and rewrite a set of things?
Yes, this hardly happened this time.
Will I continue to use TDD?
Yes.
I loved this project. I love TDD. I will definitely adhere to my future projects.
Less exploring and fixing errors. The easiest to understand the code when returning later. You only need to write tests in simple English, and you immediately know what your program is supposed to do.
It is simple like that.
The most difficult part of all of this is definitely RSPEC – it takes time to get used to:
- Mockery
- What makes fun of
- When will make fun of?
But frankly? The only way to improve this is just to continue training until the second nature becomes.
