1. You think about what you do, how your code is to be used. You consider (and maybe discover some) boundary conditions and make sure your code doesn't break on them. It forces you to think about your interfaces and make them explicit (because otherwise, how do you know how the tests should succeed or fail?).

2. Tests, even the simplest one, is encoded documentation of what works _now_. So what? If you later change something that breaks even the simplest thing, your test suit will tell you. This is regression testing. This is tangible confidence during maintenance.