Improve my health with TDD: A Software Methodology Story
Let me tell you about a boy named Pablo who works as a software engineer. This Pablo boy is a really good programmer and now he is working for a project given by his biggest local supermarket. Long story short, our boy Pablo and his team have completed the project with such a short time because he didn't even bother to have tests on their project.
It’s the 10th of April and that's a day before the supermarket's boss's birthday. A week before the boss wanted our boy Pablo to develop a feature to give a big discount to people who share the same birthday as him. It’s simple, isn't it? after all its just one small feature. That’s why Pablo smile and thinking that he can develop it for just a week.
Well, guess what? Pablo had it done and he’s ready to ship the feature right now because tomorrow is his client big day. It’s all-hands-on-deck. Pablo pushes the small feature into the production and he sleeps with a smile on his face.
“ Happy birthday”
says Pablo to his client. The feature works because his client tells Pablo that he, who has an account on his own app, got the message that tells him that he gets a big discount.
It works!
Oh but the client also tells Pablo that most of the people are bumping into bugs after Pablo’s new Feature. Because our boy Pablo is a superhuman/developer/genius, he managed to ship a hotfix in the morning before more people use the app.
Our superhero fires up his changes, and after that, the change is live. Suddenly, customer support call volume doubles. His hot-fix broke something else, and Pablo and his client are having the worst birthday party ever.
That’s story is made up and maybe exaggerated a little bit but I hope you get the point.
Why TDD?
I personally think that TDD is really useless. Yeah. USELESS. It’s useless in a world where the client never changes their requirement. Well, if there’s a heaven for a software engineer, I believe that it’s a world where the client never changes their requirement.
Jokes aside, changes in requirement or fixing a bug can lead to another bug and that will lead to developer’s fear of changes in their project.
This GIF explains it all. There’s no guarantee that our new code will not break our old code. That’s why TDD comes in rescue.TDD would make sure that our new feature or whatever new code we push, doesn't break our old code.
TDD process is so simple:
- Before you write implementation code, write some code that proves that the implementation works or fails. Watch the test fail before moving to the next step (this is how we know that a passing test is not a false positive — how we test our tests).
- Write the implementation code and watch the test pass.
- Refactor if needed. You should feel confident refactoring your code now that you have a test to tell you if you’ve broken something.
And that’s exactly what I did on my school's study project, which is given by a real client. The client is very much real and I don't really want to mess up by not implementing TDD.
So here’s what I did.
I had to make a feature to call an API. Because the real API is not yet given to me, I decided to use a Google API to test my Project.
https://www.googleapis.com/books/v1/volumes?q=devil
That’s the API that I’m gonna test and if we look at it, the API returns a JSON.
We could see that the JSON contains key named items and that’s where our target content resides. So now I get back to my Xcode and write a really simple test.
Prior to this, I already have callAPI method and its just a blank code that return an empty string and dict. I ran the tests and guess what? the test failed and that’s exactly how TDD is done.
After I write the test, I commit my test with a commit message “[RED] Create API call tests”. That tag “[RED]” means that it’s a test code. My study dictates that whenever I push tests, it should be [RED] and [GREEN] for implementation and [REFACTOR] for refactoring.
So yeah I write some implementation to call the API:
And now I ran the test and
Voila !!
My tests works and that means that the API call is a success. Now All I need to do is push it and sleep with a smile in my face. But unlike Pablo, I don’t have to worry about new features because if my new code ever breaks my projects, the test will tell me and that, kids, is how I improve my health with TDD.
Thank you for your time. I know I haven't yet to implemented the refactor part because I still need to learn how to refactor my code to be clean code with the right pattern. I hove this article helps you or maybe inspires you and if it does, please kindly share this article with the others.
Last but not least, I have some quoted on the internet.
TDD eradicates fear of change.
