What a test is for

A test is a claim about your code, written so a machine can check it. That is all. The value is not in writing it once. It is that the claim keeps being checked every time anyone changes anything.

Three benefits arrive in order.

You find out now. A bug found while you are writing the code costs minutes. The same bug found by a customer costs a call, an apology, a rushed fix and a redeploy, and it costs trust that does not come back cheaply.

You can change things. This is the real reason. Code without tests becomes code nobody dares touch, and that is how a codebase calcifies. With tests you can restructure something at four in the afternoon and know within a minute whether you broke anything.

The tests document the intent. A well named test states what the code is supposed to do, and unlike a comment it cannot silently become untrue.

What tests do not do: prove the absence of bugs, replace thinking, or justify testing trivial things. A test that checks that a getter returns what was set is noise, and a suite full of noise gets ignored.

The rule worth adopting from the first day: when a bug is reported, write the test that reproduces it before you fix it. Watch it fail. Then fix it and watch it pass. Now that bug can never come back silently, and over a year this single habit changes the character of a codebase more than any framework choice.