A bad case for unit testing is when you feel that you are fighting with the apis you are using. If you are not so sure where your program ends and the stuff around it starts, that is bad for testing.
On the other hand, it is easy to write unit tests for integer arithmetic, string parsing, compilers, etc. If a subsystem is "functional" in the sense of no side effects, then testing is easy.
The book "working effectively with legacy code" systematically deconstructs the excuses people have about why code is not testable and shows you how to make it testable. Although the title mentions legacy code, it applies every bit as much to new code.
No matter what, when you're writing code, you're doing "testing". That can either mean "run my code and see if it does what it's supposed to," or it can mean, "run a test that I wrote."
If you do the latter, the upfront time is longer -- maybe an hour -- but you save time by having automatic tests instead of manual tests.