Then there's the confidence of knowing, with fairly high accuracy, whether my changes broke anything. Then there's the value of finding out very quickly whether any of my co-workers' changes broke anything.
What are they? They are tests that you can run all the time, because they're fast. They test all (hopefully) of the external behaviors of your class. (That is, they test the behaviors that a caller should be able to count on. They don't test the internal details, because the user shouldn't care if you change those.)
Maybe the best way to learn them is to work with people who use them well - more apprenticeship than book learning.
My application has the ability to receive commands and send telemetry back over a socket to a user interface. This exposes several features in how I can test it's functionality which makes writing unit tests much easier. Good code is code that can be tested well!
Something that isn't taught but is more so learned (I've personally noticed) is architecting your software to be testable. This has really made me think about how I should write code to not just "do it's intended purpose" but also "in how it will get tested".
Start with https://en.wikipedia.org/wiki/Test-driven_development (or internet search for that term). Then look for a specific tutorial for your programming language. Each test suite has different syntax. For more theoretical approach the books by Kent Beck.