Alan Mellor is right, but in a narrow sense. Unit testing is fundamentally testing the smallest components of your program that you can test independently. It can be automated in nearly every case, but that isn’t what makes in unit testing. Automated tests are an excellent idea, but you can have automated testing at a higher level too.

What testing gives you that debugging doesn’t is a specific confirmation that a particular part of your code behaves in a particular way at a particular interface. I know that sounds like I’m being pedantic. In order to accomplish that, you have to know what behavior you’re looking for, what piece of code should be providing it, and how to verify it. It forces a clear understanding of the desired behavior so that either a set of manual steps or an automated test case can verify it.

Debugging, on the other hand, tends to focus on correcting small pieces of code, even individual statements, in order to get correct behavior at a higher level. Debugging in a broad sense is what you have to do to get a broken unit test to work. But the definition of a successful unit test is specified at the level of abstraction that you are testing. That means that your unit tests still work to test for correct behavior if you have to change the internals of your code for some reason.

Each test functions as a requirement for the behavior of your code. But it’s a requirement that is stated in a form that can be executed to determine if it is met. That produces cleaner, clearer code, as I’ve said before.