Week 5 — TDD at Println

Why We Use TDD

Test Driven Development, aka TDD, is one of the most talked-about development recently. Some truly implements it, some other hates it. But what makes us adopt TDD in our project?

• Our PPL course requires us to adopt TDD. Lol, kidding. There’s much more than that.
• It helps us to figure out how our implementation is going to be, what functionalities it needs to have, and its expected behavior. When we make the tests, we need to design as many possible cases of the function, and figure our expected output of the cases.
• It helps us find bugs. (Wait, really?) It is way easier for us to figure out which test cases succeed and which ones fail, then we can focus on debugging those failing cases.
• It helps you measure how good your application is. This may or may not work in some cases, but in my case, the fewer the tests, the more the holes of the application. When we do not test, we sometimes forgot negative cases that may happen, introducing more bugs in the middle. With TDD, we can try minimizing bugs and prevent it from the beginning.

But, TDD is Difficult…

Tell me about it! The first time I was introduced to it, this is what happened to me:

• It really, really slowed down my programming speed. It takes, like, more than 3 times my normal speed to build a simple functionality. 1 speed unit is for building tests, 1 speed unit is for my implementation, and 1 other unit is for figuring out what happened in this code.
• It tested my patience. When I first learned about unit testing, especially mocking, it took me hours (probably even days) to figure out how to mock a single function. It took me hours to mock an HTTP Request without failing all over again.

But, as we progress, it wasn’t really that bad. It truly helps me to design the expected behavior of my program, as I need to come up with as many negative cases as I can for the tests. I also picked up my speed in building the tests. It also helps me to find holes in my code very quickly, as I do not need manual testing to see where my bugs are. Well, my test coverage will tell me where I screwed up! (Don’t get me wrong, we still do manual testing, just to make it even stronger)

How We Use TDD in Println

What are the steps of Test-Driven Development?

1. Creating tests, and let them fail.
   This includes creating mock HTTP requests (if needed), preparing stubs (empty classes, empty function, and URL path) just enough to make it FAIL, not ERROR.
   Error is a condition where an exception is raised, without any handler catching it, usually because a function is not yet defined (hence we create stubs). But failing, is a condition where there is no exception, but the function does not behave as expected (because it’s still a stub, an empty function).
   In Gitlab commit, we usually tag it [RED], and have our CI pipeline failing and shows red.
2. Code the implementation to make the tests pass.
   Do your normal coding. Implement the function. Don’t forget to run the tests to make sure it passes all tests. If there is one, or more, failing tests, debug it. It is easier to trace it from failing cases as you can focus only on part of the code that may be responsible on the failing tests.
   In Gitlab commit, we usually tag it [GREEN], and have our CI pipeline passing, and shows a green tick.
3. Refactor the codes for better implementation.
   Do it as needed. Clean up the dirty comments, make better variable names, change the magic numbers to constants, and implement the clean coding. The second step of TDD was usually only focusing on how to make the tests pass, so this stage is for us to clean our codes. Don’t forget to check for the linter warnings! This is the part where I always forgot, so sometimes my tests are 100% coverage, but my CI produces errors because I kept forgetting about checking for linter warnings. No worries, after some weeks I started to get used to it, and always check for linter warnings before pushing my codes.
   In Gitlab commit, we usually tag it [REFACTOR], and have our CI pipeline passing, and shows a green tick, just as the green one. It’s because refactoring are never supposed to change the external behavior of the function.