But the best benefits (IMO) are the longer-term benefits. You'll be working on dozens of projects, and when you come back to one after not touching it for a year, you'll be amazed at what you don't remember about it. (In fact, I'm occasionally surprised when I'm asked to make changes to something--and I find that *I* wrote it years ago. I totally forgot everything about it.)
In cases like this, you'll find that it's *much* easier to change the system. You go in, read the code, make the changes, and the testing system will remind/alert you to assumptions you made this time that are different than last time. So the better your test coverage, the easier it is to make a patch "that just works".
Another thing I like: You know how sometimes a line of code or a module looks like it could be simplified or cleaned up? So you do it, and you find that it fails in some way. So you put it back the way it was. Then another person comes in and makes the same observation. (S)he comes in, does the same cleanup/simplification, and has to fix it.
Putting in a test makes it easy for you to prevent this and other types of bug regressions. Before you make a patch, make a test that forces the bug to occur, then fix it. Then if someone changes the code to re-introduce the bug, they'll be instantly alerted to it.
My final reason for enjoying test suites: Sometimes you want to make a change to a subsystem. You make it and the test suite shows you dozens of breakages. This allows you to find dependencies that you can correct, so you can further simplify your code. Some of those breakages will be unavoidable, so it will help document some requirements for your subsystem. Also, for fun, you can try to predict the breakage. This can help you keep an eye out for unnecessary interdependencies between subsystems.
There are many other reasons to make testing a primary concern, but I can't think of 'em at the moment. But you'll find them soon enough once you integrate testing into your development regime!