Today I was listening one episode of the « artisan développeur » podcast (by Benoit Gantaume) and I was surprised to hear that I was belonging to the 1% of developper that are « really » using TDD to code. YES ! I’m on the light side !!!!
Ok there are lot of 1% categories I would like to belong to, but, I beg your pardon, it is my first time ! Usually, and for all the other stuff, I belong to the 99%, so I was really pleased to hear that « news« .
To be totally honest, Benoit was estimating about 5% developpers are really using TDD. -I was glad-. And after some seconds they agree to lower this estimate from 5% to 1%. -I was furiously happy– :D.
Yes I’m really using TDD for all my laravel developments. I learned about TDD some years ago (perhaps 3) and I thought the idea was interesting. At this time, I was barely writing tests for my application. At best I had some tests scripts that I was running occasionnally. It’s not an excuse but I was developping Podmytube MVP (Minimum Viable Product) and « I had no time » to write tests.
Thinking about it now, what a stupid idea! The time you will take to write tests will be recovered a thousand time during your project life. For more than a year now every piece of function/class I’m writing, a test has been written first.
Why do you do that ? (should you ask)
For me, there were 1 key moment before I got the final « HAHA » moment » and I switched to the light side of the TDD.
The first moment has arrived after I crashed the Podmytube core application one time too much. The one that is converting youtube channel into one podcast episode. One evening, I was deploying a new version of the core, there was no reason to be worried. I went to bed some minutes after, confident that everything was fine. When I woke up on the morning I had quantities of error mails.
No podcast had been updated during this night. I was worried after all ! What happened ! It takes me some time to find the problem and to fix it, time during which no podcast was generated.
I got no angry mail or, even, phone call but I don’t appreciate to make my customers unhappy.
I started to write tests with phpunit at this time. Promising myself that i would run tests before to deploy my app update on production servers. I wrote quantities of tests to get one correct code coverage but it wasn’t TDD still. I was writing my code then, sometimes, the test. Once written I was asking myself :
Ok, and now how can I test this ?
Frequently the answer was « hum, not that simple » and I had to edit, or, worst, to change it completely. During this time, I was already listening some podcasts like « Laracasts snippets » or « Artisan développeur » and both were talking about TDD. TDD was the solution. I had read about it once in a while so I decided to give it a try.
It’s not that easy to start thinking TDD when you are writing code for more than 20 years (damn !) but I was decided to learn and not to make the same mistakes again. Finally, after some practice, I got my « Haha moment » or the key moment that make me switch to the light side of TDD (I already said that but I like this formula 🙂 ).
Think and Write the test the way you will use it your project.
I got this moment when I finally understood that before to start writing code you had to think « How will I test this piece of code/this function/this class/this feature ? ». When you start by this question, things will appear more clearly. Then :
- You start writing , the way you want to test/use the feature/class/function.
- You run the test (It fails, normal you didn’t write any code to reply the test)
- You write the code/class/feature the way the test is wanting it.
- You run the test again, and this time, test get a green/success.
- Improve it … and so on.
This sequence is really pleasant to work with and much more comfortable. You may be pretty sure that once the test get green, you may use this code in your app and everything is like you wanted to.
Growing tests library
Another benefit, once you start TDD coding, is that your test library is growing with your code. Not after, not during, not never, but before you start coding. In the future, when one test will get red, you will know that you have move something that is causing trouble. Better, you know where it happened. Fixing it is much more faster than before.
TDD is pretty much like some new « tools » I’m using now. Like docker or Laravel I will not be able to go back to previous way of coding. It’s not really the dark side but TDD is appropriate for me and probably for you too. You should give it a try too. I’m a true fan now and I’m not quite different as you :).