I've heard anywhere from 30-50% of your time is writing unit tests. However that doesn't take into account the time saved
In my experience, it's more than 50%.
Once you've written the test, the solution has a tendency to come very easy. So I don't think it's odd to spend 70% - 75% of your time writing tests, but you're spending much less time writing the 'production code' (code-being-tested) and spending virtually no time in the debugger.
The sooner you find a bug, the cheaper it is to fix, and TDD helps with that tremendously. I've worked on projects where the last 2 months (of an 8 month project) were spent fixing bugs, and that phase would be almost entirely eliminated with TDD.
To me though, the real value is in maintenance. Inheriting a code base with tests makes you less scared to alter it. You feel like you didn't break anything when the tests still pass. Since you aren't scared to make changes you're willing to refactor if something isn't right. Which means the code can be made cleaner, the design can fit better, and, in theory, changes can be applied. Contrast that with voodoo code everyone's scared to touch.
Unit Testing refers to what you are testing, TDD to when you are testing.
The two are orthogonal.
Unit Testing means, well, testing individual units of behavior. An individual unit of behavior is the smallest possible unit of behavior that can be individually tested in isolation. (I know that those two definitions are circular, but they seem to work out quite well in practice.)
You can write unit tests before you write your code, after you write your code or while you write your code.
TDD means (again, kind of obvious) letting your tests drive your development (and your design). You can do that with unit tests, functional tests and acceptance tests. Usually, you use all three.
The most important part of TDD is the middle D. You let the tests drive you. The tests tell you what to do, what to do next, when you are done. They tell you what the API is going to be, what the design is. (This is important: TDD is not about writing tests first. There are plenty of projects that write tests first but don't practice TDD. Writing tests first is simply a prerequisite for being able to let the tests drive the development.)
Best Answer
Automated Tests are tests that are automated, i.e. tests that don't have to be performed manually.
Test-Driven Development is a Software Development Methodology in which Tests drive the entire development process. In order to drive the process, writing tests needs to be the very first thing you do; when you have written a failing test, the test tells you what code to write, which code to write next, and when you are finished writing code. The tests are the driver for the entire development process.
The two don't really have anything to do with each other (apart from the fact that typically, the tests used in TDD are automated tests), so asking about their difference is about as meaningful as asking about the difference between a Toyota Corolla and the color blue.