I would recommend Kent Beck's book on TDD.
Also, you need to go to Martin Fowler's site. He has a lot of good information about testing as well.
We are pretty big on TDD so I will answer the questions in that light.
Should tests be in the same project as application logic?
Typically we keep our tests in the same solution, but we break tests into seperate DLL's/Projects that mirror the DLL's/Projects they are testing, but maintain namespaces with the tests being in a sub namespace. Example: Common / Common.Tests
Should I have test classes to mirror my logic classes or should I have only as many test classes as I feel I need to have?
Yes, your tests should be created before any classes are created, and by definition you should only test a single unit in isolation. Therefore you should have a test class for each class in your solution.
How should I name my test classes, methods, and projects (if they go in different projects)
I like to emphasize that behavior is what is being tested so I typically name test classes after the SUT. For example if I had a User class I would name the test class like so:
public class UserBehavior
Methods should be named to describe the behavior that you expect.
public void ShouldBeAbleToSetUserFirstName()
Projects can be named however you want but usually you want it to be fairly obvious which project it is testing. See previous answer about project organization.
Should private, protected, and internal methods be tested, or just those that are publicly accessible?
Again you want tests to assert expected behavior as if you were a 3rd party consumer of the objects being tested. If you test internal implementation details then your tests will be brittle. You want your test to give you the freedom to refactor without worrying about breaking existing functionality. If your test know about implementation details then you will have to change your tests if those details change.
Should unit and integration tests be separated?
Yes, unit tests need to be isolated from acceptance and integration tests. Separation of concerns applies to tests as well.
Is there a good reason not to have 100% test coverage?
I wouldn't get to hung up on the 100% code coverage thing. 100% code coverage tends to imply some level of quality in the tests, but that is a myth. You can have terrible tests and still get 100% coverage. I would instead rely on a good Test First mentality. If you always write a test before you write a line of code then you will ensure 100% coverage so it becomes a moot point.
In general if you focus on describing the full behavioral scope of the class then you will have nothing to worry about. If you make code coverage a metric then lazy programmers will simply do just enough to meet that mark and you will still have crappy tests. Instead rely heavily on peer reviews where the tests are reviewed as well.
