Learning to Code the TDD Way

I had come across TDD(Test Driven Development) a few times prior to my application to Andela, but I never took it seriously enough to set aside the time to learn what it was or how it worked. All I really cared about then, was the fact that my code was working alright. I mean why should anyone be worried about anything else.

But as I would come to understand later on, when writing code professionally or working on huge codebases, manually testing out individual units or modules of code could be a surprisingly tedious affair and is at times far more difficult than writing the implementation code itself.

Funnily enough, I had imagined TDD to be some kind of software you simply install on your system, launch and then click a few buttons and voila, all your code is magically tested and then you get a bunch of sophisticated results. I also wondered what the criteria for the tests would be. Was it the structuring or neatness of the code, or the code’s adherence to best practices or probably the presence or absence of syntax errors. To be frank, I had no idea but one thing was sure at this moment, I was sufficiently curious.

So I dived into Andela’s Homestudy and started reading up all the articles listed in the TDD section. In some minutes I got the answer to my first question, TDD definitely wasn’t an application designed to do all the dirty work for you in a matter of seconds, but instead, the tests were code itself and it was manually written and run. So, in essence, we basically write code to test out some other code.

After I had gone through an article or two, I found out that TDD is simply a method of development where unit tests were written first before the actual implementation code was written. You get to write tests that use a piece of code as if it were already implemented.

It followed a Red, Green Refactor cycle, in other words, the test fails at first (in fact, they are supposed to fail at this point because you are yet to write any code), the next step would be to write the smallest amount of code required for that test to pass, and after it passes the code is refactored.

I was literally amazed, with the way the tests were implemented. Using testing frameworks like Jasmine or Mocha you could write unit tests that call functions, supplying arguments and then check to see if the results got are actually the expected results. Some assertion libraries like Chai allow one to make HTTP requests to endpoints. In a nutshell, TDD serves as a tangible way to measure out the effectiveness of your code.

After a few days of studying and practicing TDD, I had found out some specific reasons why TDD was such an important tool in software development.

In the end, I was happy because I had gained some vital experience about one of the most popular methods of software development and it was worth it.

Related posts:

Yesterday morning I woke up hoping the exit poll was a bad dream. Although the actual result wasn’t quite as bad what was predicted by the exit poll, it still didn’t make me feel any better about it…

The Business Dept is happy to announce that as of Saturday Sept 21 02:00 UTC, the issuance of ROMAD smart token has ended. Distribution is now complete. Valid TGE (token sale) and bounty participants…

How it hides behind objects, peering and waiting to creep out and delight us grey creatures with its mystical glow. In summer, to brighten up our days for hours on end strutting arm in arm with its…