What I've Learned About Testing
Published Date: May 2025
Technical
Table of contents
Introduction
On August 2024, I got the offer in my current workplace. Before I got the offer, I was interviewed and told by the Engineering Manager that soon I would be work with that they implemented the Testing Driven Development as a culture and every member should be aware of it.
The first response in my mind is "Oh, I have to learn about testing, because I never work with TDD before". Thank God, I got the chance to consult with mas Irfan Maulana who was a Senior Frontend Engineer at several big companies in Indonesia.
I still remember I set the online meeting with him on August 23, 2024. We discussed so many things about testing, started with the why's until the tradeoffs. I learned a lot from him, and I want to share what I've learned about testing in this blog post.
This blog actually a quick contemplation from me about testing implementation😅.
Why We Need Testing?
We write tests to be confident that our application will work when the user uses them.
The quote above is quoted from Kent C. Dodds. We need to make sure that our application works as expected. We need to make sure that the code we write is correct and does not break the application. We also have to be aware that the code we write is maintainable and easy to understand.
Also, every changes that we made to the codebase should not break the application. It should be testable and easy to test. We have to make sure that the code we write is easy to refactor and easy to maintain.
Test Types
The image below is the visualization of the test types (Testing Pyramid/Trophy):
Kent C. Dodds share in his blog, there're 4 types of tests that we can use to test our application:
- Static Tests: These tests are used to check the code quality and code style. Remember, these are not used to check the functionality of the application. It checks the code quality and code style. If you already familiar with ESLint, Prettier, or TypeScript, these tools are the examples of static tests. These tests are used to check the code quality and code style.
- Unit Tests: These tests are intended to verify the functioning of a particular piece of code. It verifies that individual, isolated parts work as expected.
- Integration Tests: These tests are used to check the functionality of a group of units of code. It verifies that several units work together in harmony as expected.
- End-to-End Tests: These tests are used to check the functionality of the entire application. It also check the functionality of the entire application from the user's perspective.
Test Trade-offs
Cost
Test prices increase in tandem with the number of test kinds. The time and effort required to develop the tests is the test's "cost." Maintaining the tests requires time and effort, which is the test's cost. The time and effort required to conduct the tests is the total cost of the testing.
Speed
As the test types goes up, the speed of the tests goes down. This is because of the scope of the tests that is getting bigger. The bigger the scope of the tests, the slower the tests will be due to the time and effort required to run the tests.
Confidence Scopes
As the number of test types increases, so do the test's confidence scopes. The confidence scopes of the tests represent our confidence that the code we produce is manageable and easy to comprehend. The more the tests resemble the way the software is used, the more confidence they can give you.
Conclusion
So where I should start? Start Small.
Start from the smallest test type, which is Static Tests. You can start with ESLint, Prettier, or TypeScript. After that, you can start with Unit Tests. You can start with Jest or React Testing Library, because those are the popular library that usually used for unit testing. The Integration Tests and End-to-End Tests are the last tests that you can implement later or if you've already have bigger resources.
And this is the most important thing. The popular approach is write the test before you write the code. But in my opinion, you can write the test after you write the code. The most important thing is to make sure that the code that you write is correct and does not break the application.I even still write the test after I write code.
With current AI Assistant, you can utilize it to write the test scripts. Don't be confused on what you should test. Utilize the AI, you can learn it along the way. Here's my test script examples that I used in my current personal web: https://github.com/yehezkielgunawan/yehezgun-v5/pull/65/files.
This is the closing statement from Kent C. Dodds:
What I'm interested in is whether I'm confident that when I ship my changes, my code satisfies the business requirements and I'll use a mix of the different testing strategies to accomplish that goal.