TDD the necessary devil
Truth be told, I did not like anything to do with writing tests for my code at the very first time I came across TDD (Test Driven Development) as the whole idea of it seemed so bizarre to me.
Writing tests before writing any functional code and then writing only the least possible amount of code required to make your tests pass just sounded more time wasting.
As usual in my leisure time, I happen to watch air crash investigations and in this program, the investigator spend a lot of sleepless hours trying to figure out the cause of the various aircraft crashes and to them, even the smallest particle of the plane contribute greatly to knowing the possible cause of a particular aircraft crashing down; And usually the number one cause of most air crashes is human errors (pilots or engineers).
This has always made me think so hard on how so many die just because a few humans ignored to perform that required procedures and since I am a no better human than them, so prone to ignoring certain key principles which could cost my clients lost of money & life probably.
So I decided to adopt the devil I unwelcomed in the first place and now I can tell you that am becoming a better developer who moves faster with clean code & on which I can even guarantee on the reliability of software functionalities I develop.
But this didn’t come that easily. I had to sit my brain down & convince it to accept the idea and trust me this was one of the hardest tasks in life, luckily enough it didn’t take long. Being a python developer of late, I started right off with unittest which is a python built-in testing framework which introduced me to interesting modules like setup() which helps to bundle up all resources needed by each test to be successful & teardown() unbundle the resources when all tests are complete. I then moved onto learning pytest which makes it much easier to write small tests, yet scales to support complex functional testing for applications and libraries.
After this, I came across some more interesting tools which you work along with to have continuous delivery of tested and clean software functionalities like TravisCI and coverage which helps one to know how much of the written code is covered by the tests.
Though this approach sounds bizarre and a burden, but it’s not. It's such an approach which will enable you to deliver quicker less breaking systems.
Signing off with saying thanks to Andela Uganda for introducing me to this approach would be a cheat. So Thank You Andela & to all various Andela team especially Frank Odongkara & Prossy Nakimera who have helped me to capture this skill
Happy TDD coding.
