Search code examples
unit-testingtesting

Why should I write unit tests when I can use Postman and debugger to check my code?


I was very interested in writing tests and benefiting from the advantages of coding in a TDD environment and/or just boosting my applications' reliability.

But upon reading more and implementing some unit tests in one of my projects, I wondered why should I spend extra time writing tests whereas before, I used Postman and the compiler's debugger to check my logic and it worked fine.

I understand that by writing tests we can have a better understanding of the process's flow or catch errors that otherwise would've been hard to find, etc; But I was wondering whether it's worth the trouble of spending more time and writing extra code.


Solution

  • This isn't a well-suited place to answer such as wide question, but I'll give a few pointers that you can use to dig further into testing and it's gains.

    There are many more goals of tests than to just verify that a test returned the same thing you verified with postman or what you saw in your debugger (you can also write test suites in postman) at that time.

    The most obvious feature comes the next time you change any code that should or should not touch what you verified manually earlier - suddenly you get verification that the old code still works in the same way as it did when you wrote it. The behavior hasn't changed because of what you did this time, and any code relying on the old behavior should still work. Unless you have automated tests you can't really be sure that your recent changes hasn't changed existing behavior.

    This creates a safety net that allows you break less things as the project grows.

    Having code that is testable also forces separation of concerns for the interface being tested (HTTP/interface/class/method/etc.).

    These tests will also work as simple documentation of how your API is supposed to be used for new developers, and allows new developers to be more confident in their changes to the project.

    Writing tests should also make you think "what are the edge cases here?" and write tests that expose those edge cases and verify that they work as expected.

    You still test your code when you do it manually, so instead of just making that knowledge disappear when you're finished with a piece of code, formalize it as tests and make it available for the future as well.

    There will always be a slight overhead of writing tests - in particular learning a test framework, how you test, and how you write code that is testable, but as with everything else, as soon as you get into the flow, it becomes second nature.