Also I don't agree with GP, there are places that require unit tests, especially if multiple people are working on a project. You could be a developer that never made a bug in your life, but others might not be as great :) besides many bugs also happen by changing other parts of the code. Some of your assumptions might have been 100% correct when you wrote the code, but someone can change different part of the code and now your function is called with values that were previously impossible.
The great thing about statically typed languages is that they might detect large part of these bugs, but you're out of luck with dynamically typed languages.
Example of this was the Python 2 -> Python 3 migration. Having a large test suite helped tremendously.
Using tests as a way of finding problems seems like not a great way of saying code has issues x,y, and z but they are a great of saying something does a, b, c. If you are going through a refactor you might not be implementing a, b or c correctly anymore and if your tests are designed well this will be caught.
If we are only talking about bug catching, you are right there are better tools. But I'll say if somebody says code does something and there are no tests demonstrating that fact, I don't trust it generally unless it's something like a game where it's hard to test certain things.
there are two different types of formal proofs:
1. there is at least one error in the code, or
2. there are no errors at all
The [1] is much easier than [2].
Unit tests are a tool to get you to working code.