I'm in TechEd at the moment and I am sitting in a presentation on Unit Testing. Unit testing is something we have been doing on my teams for some time now and it is an intricate part of our development process. I am a big believer in continuous integration for development and part of the automatic build process includes a unit test run through the application/component that we are working with. The results of the unit tests are then deployed (automatically as well) to a server and made accessible to everyone on the teams as well as dependent teams within the organization.
BTW a good book on establishing this entire process yourself is Code Leader by Wrox.
"There is no such thing as "done". Much more investment will be spent modifying programs than developing them initially." - Beck
The session focuses on the concept that the development of your application is the smallest part of the process and much more of your time will be spent fixing and modifying the first results of your work.
The speaker here is a believer in that you can have more than one assert per test. There are many that don't believe this, but it makes more sense to test *one* thing, which may involve multiple assets. It definitely doesn't make sense to have multiple asserts to test multiple things.
Also - make sure that you keep your tests similar to your code. If what you are testing is in one assembly, do the same with your tests. The benefits of keeping your tests close are making sure that your tests are equivalent to production code and it solves any visibility problems.
We ourselves used to use NUnit testing, but have recently switched to Microsoft's testing framework as it allowed us to put a timeout in our tests, something the latest NUnit tests are unable to accomplish.