When we write a new software I write unit tests at least for the essential parts and try to convince the team to do the same.
(And when I'm with the estimation team I add unit tests to the items to be calculated.)
But when we add something in old, grown software there's no way to get weeks of additional budget for unit tests.
And I don't see much sense in writing unit tests covering 0.1% of the code.
It's the process of debugging your application by means of getting the compiler to produce an EXE file.
Once it stops issuing ERROR messages (WARINGS are fine, you can ignore them) you're ready to ship!
"Unit" testing is just an Acronym for this process: "yoU Need It Tuesday"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
Yes, I remember during the good old FORTRAN or C days, they used to say that each subroutine or function is to be tested by giving several valid inputs, and several more invalid inputs, and then the response seen.
For example, for a numerical argument, give input within range and at the boundary (for valid inputs), and outside range, one-off inputs, alphanumeric, decimal, integers, negative numbers, etc. (for invalid inputs).
Similarly for strings.
Faintly remember that it used to be called Equivalence Group Testing. Quite fail-proof. Not sure whether it is still being used.