TDD, Test Before Code?!?! Is that even possible?
I think, as a programmer when we were given a problem, we tend to jump straight to coding the implementation. When it comes to a small scale of a project, it usually doesn't have any problem with that method. But when we face a problem on a large scale of the project, jumping straight to coding is ideally not a good idea. It because a large project tends to have a lot of changes and relation between service. To solve this problem, we need to make the right design of the problem in a form of a “test”, and it called TDD or Test-Driven Development.
I know, at first, most of us find that TDD is just weird and contrary to common sense. Like how do we make a test without knowing the implementation of code, isn't that just adding a lot of work to our project?
I hope in this article I can change that opinion and make TDD more interesting to you guys.
What is TDD?
Test Driven Development (TDD) is software development approach in which test cases are developed to specify and validate what the code will do.
So what is exactly is a test case? A test case is a type of code that will verify our implementation code. It can verify our code by comparing the output when we run some input on our code to the real output that we want.
And there's another important term that we will discuss, a Unit Test, its a type of testing where we test specific individual units or component of our codes.
So that's the definition of a test. Now let's discuss the real deal. What is TDD?TDD is a software development technique that makes us design a unit test before we write the implementation of the code. I know the definitions sound easy to do, but when it comes to real-world implementation, it can become challenging and time-consuming. But the advantage of making a TDD is far bigger than the drawbacks, so that's why a lot of professionals using TDD on their daily work projects.
It sounds counterintuitive, how in the world do we know what to test before we write the code? I know most of us will think about this question, I got it, this is my feeling when I first learning about TDD. In the first time using the TDD process, we will face a hard time to think what type of test we need to write, because we don't know the exact implementation of our code. The thing that we can do about this is practicing and practicing, like 40 hours a day, (JK lol). Don't forget to learn from someone that has a high experience with TDD, it will help us a lot when we can learn things from someone.
So, How do we do TDD?
There are 5 crucial steps for doing a TDD
The steps are:
- Understand the problem; the first thing you need to do literally before doing anything is read and understand the feature or unit that u want to make.
- Writing a unit test; Now the hard and unknown step, translate your understanding of the requirement by writing a unit test for our code. After we write our test code, we will run it and of course, it will fail, because there's no implementation of the code. Thats okay, or rather that's the point of this step, it is to write a fail test case, that will make our pipeline turns red. And that's why this step usually called the RED step.
- Write a code; The fun part, we need to write and implement the code that we want to make and fulfills the requirement. In this step, our goal is to pass all the tests that we have been made in the previous step. If when we run and there are still some of the tests that fail, we need to repeat the coding process until all the tests are passed. When all the tests passed, the pipeline will turn green, and that's why this step usually called the GREEN step.
- Clean your code; In this step, we can clean our code by refactoring. It consists of making your code more readable without changing the implementation or changing some not technical stuff, like styling or code design. This step usually called the REFACTOR step, and we already know why.
- Repeat; And the last, or not last, we have to repeat all these steps until the project is done. But I think, there's no such thing as “done” in the software development process, so we just accessing a time loop at his point, Congrats.
In the paper, TDD methods look easy to understand. But in the implementation, we really need to work so hard to understand this. But at the end of the day, it will be worth it because we don't have to spend so much time finding bugs and cleaning them.
Example
I hope now u have become more interesting in TDD, and now I want to show you guys an example of TDD that I use in the University project. In this project, we want to build a school registration website, called SekolahKu. Currently, I'm working on user registration. Before I write the code implementation, I write some test case to check if user register with no data will return error code and check if user register correctly, will return their username and email, and success status code.
First of all, we need to write the setup for all the test cases. This setup is consists of the URL that the test should access, and the dummy user data for registering the app.
After that, now we can write our test cases. The first test case is tested for the user cannot register with no data. In this test case, we post the blank form to the URL and expect that method will return 400 status codes, because of a bad request.
The second test case will be tested for the user to register correctly. In this case, we post a correct form of registration to the URL and expect to get a 201 success status code. On top of that, we need to expect that the post will return our user data again, so we need to test that too.
Now we must push to the pipeline to see if the test fails or not.
And now we need to add our user registration implementation to our code, and the code will look like this.
Now we need to push it to the pipeline and hope that all the tests passed, and the pipeline turns into [GREEN].
If all the test is passed, we can edit our code to clean up a bit at refactor step, and now our first cycle of TDD is done. Yap now our simple register implementation is done and that's an example of TDD in the real problem.
Conclusion
I know at first TDD is making us confused and takes a lot of our time. But in a long run, TDD will help us a lot, and with practice, TDD will be a lot easier to implement. And I think that's all for my article, I hope this article helps you guys understanding TDD a little bit more.
source
https://tahins.medium.com/the-mindset-behind-test-driven-development-tdd-b02deccbff81
