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.

CodePudding user response：

You don't run unit tests to check whether the code you're adding works. You run unit tests to check that the code you're adding doesn't break the existing code.

When you write a new unit test, it doesn't provide any value immediately, because it is just testing that your new component / class / function works as expected, which, like you mentioned, you can easily check yourself using other tools, without taking the effort.

However, the more your application grows in complexity, the more unit tests become invaluable. You don't want to manually test the entire application to check if a new change doesn't break something. You want to have confidence that existing code is still intact after the changes, and unit tests (as well as other types of tests) give you that confidence.

In short, it's much, much better to spend 1 extra hour per feature to write a test, than to spend countless of hours in the future fixing unexpected bugs.

CodePudding user response：

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.

CodePudding user response：

In a more complex project, unit tests will help you test every functionality of your code without having to manually check if it is still working.

So unit tests will save time you would be spending on manually running the tests in postman.

CodePudding user response：

Rant Writing good tests is difficult and time-consuming. This means, it requires skilled programmers and a lot of time. Therefore it's sometimes hard to explain the requirement to do it anyway to any kind of management. They don't want to spend $$$ on expensive people for a long time.

Now about the real question Unit tests, when done right, can and should be run after each build of the software. They confirm that whatever once worked still does. Therefore it prevents accidental changes to the code you didn't intend. Of course, a failing unit test not always means trouble (maybe you need to update the test), but it definitely means that something has changed where you didn't expect it. Repeatedly running a potentially large set of unit tests is much cheaper than doing the testing manually each time. The time you need to debug stuff costs your boss $$$ as well.