New to TDD? Let’s dive into it!
Test-driven Development (TDD) is a discipline that helps software developers deliver clean and flexible code that works, on time. TDD is an integrated part of developing software method, it’s not just testing software. In TDD, we must first write the test and then we can go to production code. We set a definition of done before the actual code implementation. With TDD, we can test each line of code that we write without needing a lot of effort or wasting time by manually checking. But why do we need to create tests? There are a lot of advantages on creating tests. Test will save your time, tests don’t just identify problems but they prevent them instead, tests make your code more attractive, and tests help teams work together. There are three laws of TDD:
First Law You may not write production code until you have written a failing unit test.
Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law You may not write more production code than is sufficient to pass the currently failing test.
In writing tests, we must follow these 5 rules on creating a clean tests (F.I.R.S.T):
- Fast: Tests should be fast and run quickly so that we can fix them easily if we find a problem.
- Independent: Tests should not depend on each other and one test should set up only for one condition.
- Repeatable: Tests should be repeatable in any environment, such as a production environment or any other environment.
- Self-Validating: Tests should have a boolean output whether it is pass or fail.
- Timely: Tests need to be written in a timely fashion, which is just before the production code to make them pass.
TDD Cycle
Red
In this phase, we write a little test that doesn’t work, perhaps doesn’t even compile at first. Make sure we include all the possibilities we can think of for the input and output. Run the test, and make sure the test fails because there isn’t any code yet to make the test pass.
We can commit to the repository after we finished writing the test. It stated in the commit message: [RED]
Positive Test
A positive test checks if a function/method behaves as expected with its expected input.
This is the test that I made for the commit above:
Negative Test
A negative test checks if a function/method behaves as expected with bad input.
This is the test that I made for the commit above:
Green
In this phase, we make the test work quickly, committing whatever “sins” necessary in the process. Type the minimum working code in order to pass the test. This will keep the developer focused and provide clarity on what should be implemented.
We can commit to the repository after we finished the production code. Make sure it passed the test. It stated in the commit message: [GREEN]
This is the production code that I made to make the previous test pass:
Refactor
In this phase, we eliminate all the duplication created in just getting the test to work. Refactor the code, do some cleaning, and DRY-ing. As long as the test is still passing, it means there is no problem with the refactored code.
We can commit to the repository after we finished the refactor code. Make sure it doesn’t change the previously passed tests. It stated in the commit message: [REFACTOR]
Difference Between Frontend and Backend Testing
Frontend
Since I use React, for frontend testing I use Enzyme, Jest, and React Testing Library. Front end testing is basically performed on the user interface (UI). Frontend checks the overall functionality of the application. Frontend testing examples are Unit Tests, Acceptance Testing, Accessibility Testing, and Regression Testing.
Backend
Since we use Django for the backend, we use the unittest module built-in to the Python standard library. Backend testing is performed on the database and application user interface (AUI). Backend testing examples are SQL Testing and API Testing.
Well, from what I experienced, the frontend is easier to develop than the backend. But, for the testing, I think frontend testing is more difficult and complicated. Frontend code changes more frequently than any other piece of code. You are probably going to introduce more bugs on the UI than anywhere else. Testing is linked to the actual design and execution of the UI and soon becomes redundant. Plus, the use of CSS selectors makes the test terribly unreadable and hard to maintain.
Well, that is a little explanation of what Test-Driven Development is. You can still dig deeper into TDD. I know maybe it’s quite hard at the beginning but you will expert it after many practices. So, happy TDD!
Source:
- Clean Code by Robert C. Martin
- IT Project Programming Guideline
- https://www.geeksforgeeks.org/difference-between-frontend-testing-and-backend-testing/#:~:text=Front%20end%20testing%20is%20basically,application%20user%20interface%20(AUI).&text=Front%20end%20checks%20the%20overall,data%20corruption%20or%20data%20loss.
- https://www.guru99.com/frontend-testing-vs-backend-testing.html
