Have you ever heard of TDD, or Test-Driven Development? Don't worry, I'm not here to convert you to TDD — I'm not an extremist. I simply want to share how a laid-back software engineer like me became addicted to testing. To me, testing is "fulfilling." I know some of you just want to get the job done (I did too), but is it fulfilling for you? Or is it just a tedious routine?

As software engineers, our primary job is to code, but is that all? I used to think like that, until I'm thinking about the users, the one who use our applications, unless you're solopreneur and you're the only users please just close this tab, No! Stay here!

We live in a complex world where everyone's priorities differ. While you're reading this, someone else might be watching Netflix, streaming on Twitch, or spending time with family. Meanwhile, someone could be stuck in a hospital administration process during a critical moment because the system crashed after a weekend deployment by an unpaid intern. Reflecting on this, it's alarming to realize that our actions could significantly impact someone else's life, potentially even in life-and-death situations.

Software engineering is fundamentally about people. We code so others can use our applications. Before the advent of software systems, people interacted directly with bank tellers to withdraw money. Now, systems handle those transactions. Despite the shift from human-to-human interaction to human-to-system interaction, the core value remains the same: to serve the user and help people.

Why complicate things by adding tests to the code? It's not just about the tests; it's about considering yourself as a user. Testing doesn't start when you write code; it begins when you plan what to build. Take this Gherkin syntax for example:

Given I login to the system
when I click add to cart button
Then the item should added to my cart

Even before development starts, you've already thought about what the user will do and the expected outcome. This way, you won't be working blindly, unsure of what to focus on.

Testing manually takes a lot of effort. You must write your code, go to the UI, log in, generate data manually, and ensure that all criteria are met. You can always speed this up by not testing at all, but really?

Here's some good news: "Unit Tests." Instead of manually testing everything repeatedly, you can write code to automate these tests under different scenarios. Integrate this into your development workflow, and these tests will run automatically.

Yes, writing unit tests takes more time and effort, but the problem isn't the unit tests; it's the perception. You should see testing as part of the development process. Include it in your timeline. "But it's costly!" says the product manager. The cost of unit tests isn't an expense; it's an investment. It's not just the product manager's job to think about the users; as software engineers, we should too. In a user-oriented team, unit tests become second nature.

Do unit tests guarantee a production error-free application? No, and that's okay. It allows room for improvement and further learning. These insights enable us to tackle bigger challenges in the future. So, should you test or not? That's up to you. But remember: someone out there is using your application. I find it fulfilling to ensure the best experience through thorough testing, and I hope you will too.

Does writing unit tests guarantee a production error-free application? No, and that's actually beneficial. Why? Because it allows us to continually improve our tests and gain knowledge about what to consider in our software engineering journey. This accumulated knowledge then becomes a valuable tool for tackling even bigger challenges in the future.

After all, the decision to test is yours. But remember, someone out there relies on your application. For me, it has always been fulfilling to write unit tests and provide the best quality I can. For you, it might just be a line of code, but for the user, it could mean so much more.