First Thing First: TDD

Code bugs can be considered as a programmer’s worst nightmare. But, there’s a way to detect bugs early so one can sleep peacefully at night. If you guessed Test Driven Development, congratulations, you are correct!

source: https://blog.usejournal.com/test-driven-development-understanding-the-business-better-9c4cae4cb990

Test Driven Development itself is a cycle. It consists of RED, GREEN, REFACTOR.

RED

The first thing to do is to write a failing test before we code the actual implementation. However, Robert C. Martin on the Clean Code book said that this is only the tip of the iceberg. Instead, we have to examine The Three Laws of TDD:

1. First Law: You may not write a production code until you have written a failing unit test.
2. Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3. Third Law: You may not write more production code than is sufficient to pass the currently failing test.

These laws will help us ensure that all of our production code are covered.

Writing a clean test is not less important than writing a clean code. Clean code should follow these 5 rules that we call F.I.R.S.T:

1. Fast: Tests should be quick so developers can find the problems (bugs) and fix them easily.
2. Independent: Tests should not set up the condition for other test, as they should not depend on each other.
3. Repeatable: Tests should be able to run in various environments.
4. Self-Validating: Tests should have a boolean output either pass or fail.
5. Timely: Tests should be written exactly before the implementation code that makes the pass test.

During the red phase, our group wrote tests first for the Product Backlog Item (PBI) that we’re going to implement. I was going to create a new dialog UI so I wrote the code first. Here’s the code for the test:

After that, commit the test to the remote repository. The commit message should be in this structure: “[RED] <your commit message here>”. Here’s an example for your reference:

GREEN

After done with writing our tests, now we can write the implementation. Yay! But that doesn’t mean we can write ALL implementations. Remember the third law, we should not write more production code than is sufficient to pass the failing tests. Here’s the implementation code from our previous test:

Once finished, commit the code to the repository with a commit message that starts with [GREEN] followed by your commit message. Here’s another example:

REFACTOR

In this phase, we can change our code but all of our tests should still pass. We remove code duplications and ensure our code is clean in this phase. If we want to commit our refactored code, make sure to start your commit message with [REFACTOR].

Here’s an example:

There’ll be classes, methods and BLoCs for the implementation of Donasi Barang (Goods Donation). Following the clean code rule and also to make it less confusing, I changed the existing Donation class, methods and BLoC to MoneyDonation.

Even if some people think that TDD is a hassle, I do think TDD definitely worth the time and effort. It makes sure our code suits the acceptance criteria, so one step closer to mark a user story as done!

Source:

Clean Code book by Robert C. Martin