Test-Driven Development — Savior and protector of your project.

This article was written to help you with basic knowledge of TDD and as an individual review assignment of PPL CSUI 2021

The first time I learn about TDD, the methodology of writing tests before writing code is absurd. I think that it is not useful and slows down the development process. Then I keep asking why I need to do these things?

Until one day, I work on my project that not adapt testing on it. The project getting bigger and complicated. Then “BOOOM!”, bugs occurred. I need to recognize what is happened and how to fix it. The bugs unrecognized and the project ended up just like that. At first glance, we can agree that TDD takes a long time and it does impact the speed of development. But, what’s the point if the system that is built is not strong and sturdy.

Test-Driven Development is a guarantee of the program that will be built. It helps the developer to deliver code that functional, readable and maintainable. This is a claim that developers can use to make sure the system is running properly.

What Is Test-Driven Development?

Test-driven development is a technique that helps the software developer to write clean and well-deliverable software where a test is written before the software developer creates the production code to fulfill a test.

then, how It works?

The image is taken from agilenutshell

1. Understand the User Stories and Case. At First, The developer must understand the requirement and specification of the feature to be built. It is needed to make sure the developer knows the problem domain well.
2. Write Fail Tests [RED]. All new features start with the writing of a test. In this step, we need to write a test for the feature. The test will fail because the code has not been implemented.
3. Start to Code. The developer writes the code to implement the functionality of the features and pass the test.
4. Test the code [GREEN]. Re-run the test. Make sure that the implemented code passes the test. If the test fails, back to step 3 to debug the error.
5. Refactor Code [REFACTOR]. Here, The developer improves the performance and readability of the code that had been written. For example, reduces duplications, implements better algorithms and other ‘clean code’ things.
6. Repeat. Repeat all the steps above to all features implementation.

Why we do TDD?

• Rapid feature feedback. With TDD, the unit-test can run automatically. It provides feedback faster during development and debugging sessions than manually test each change.
• Better code coverage. Code coverage is a percentage of how the test code coverage the feature implementation code. Because we code the implementation code based on the test code, the coverage will close to 100%(no code that was not tested).
• Friendly for the code change. In software development, code changes are inevitable. If in a time a code change s introduced to failing a test, the developers are notified quickly to fix it.
• Confident to deliver ready-product. TDD gives the developer faith about how good the program that they build. The test was built to handle all possible cases so the product can reach the customer well.

How to write a test?

There are 4 main kinds of test

1. Unit Test. Here we test all components in the code independently.
2. Integration Test. It tests all the integration between modules that related to each other.
3. Functional Test. Test all the functionality of the implemented features.
4. Load Test. To test the ability when the systems face a heavy work state.

A good test should follow the FIRST Principle

• Fast. Tests should be fast and run quickly so the developer can fix the bugs instantly.
• Isolated. Never write tests depends on other test cases and set up only for a condition. It helps you to minimize the test chain so you only need a small amount of time to figure out the error.
• Repeatable. Design a test that repeatable in any environment, such as staging environment or other.
• Self-validating. Tests should be able to verify the output is failed or pass.
• Timely. Write the test in a timely fashion which is before the code is production-ready.

Example of TDD

I will give you a hands-on explanation using TDD in Gitlab. You can see on my commit history, there are 4 kinds of tags; RED, GREEN, REFACTOR, and CHORUS.

sorry for the pipeline because at the time GitLab was down

RED

example of a RED commit

The RED tag is used to commit your test. The test should fail because we need it to be solved in the next tag. In the example above, I made a test for a component in the front-end using React called ServiceCard. In the front-end testing, we need to make sure that the element that we want guaranteed to appear on the page. In my case, The service card needs to show one typography and two grid elements.

GREEN

example of a GREEN commit

The GREEN tag is used to passing the test that you have made before. Here we start to implement the code. The code does not need to be perfect, but the important one is it passes the test.

REFACTOR

example of a REFACTOR commit

The REFACTOR tag is used to improves the performance and readability of the code that had been written. For example, I have a naming issue in the image above because I want to implement a ServiceCard, not ServiceButton. All the change I made to fix it is wrapped into one commit with tag REFACTOR.

CHORES

example of a CHORUS commit

The CHORES tag is used to make a change that does not implement a new logic or functionality to the application code. For example, the addition of image assets and DevOps dependency. In the image above, I want to make Gitlab ignore a few files, so I need to change the code in the.gitignore file so the Gitlab will ignore it to be pushed in the remote repository.

End Words

Thank you for your enthusiasm to learn Test-Driven Development. I hope this article can help you with your project and assignment.

Reference

Buku Panduan Git Flow PPL 2021

Buku Panduan Git Deployment PPL 2021

Buku Panduan Definition of Done PPL 2021

howtodoinjava