首先，给出MSDN相关地址：http://msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.TestTools.UnitTesting.aspx (类库)
Verifying Code by Using Unit Tests (介绍)
我的IdleTest源码地址：http://idletest.codeplex.com/
VS2012单元测试的主要类：Assert、StringAssert、CollectionAssert，具体可参照上述链接的MSDN介绍。
单元测试一直都想接触，但是碍于没有那样的工作环境，故只能由自己在业余时间去做这个事，整个过程下来，最大的感触是我写代码的质量原来可以这么好，在此之前，通常我编写的代码有很大一部分在程序运行前都是有bug的，但是通过单元测试，基本上在程序运行之前（调试阶段）就扼杀了这些bug的大多数，单元测试代码有问题除外，这也是我坚持单元测试的最大动力，其次就是单元测试可以促使我在编码中努力去遵循SOLID，提别是单一职责原则。
我个人在学习单元测试中基本都写成了博客，便于记录，以下为目录。
目录：
1.《在Visual Studio 2012使用单元测试》、
2.《VS2012 单元测试之泛型类（Generics Unit Test）》、
3.《VS2012 Unit Test —— 我对接口进行单元测试使用的技巧》
4.《VS2012 Unit Test（Void, Action, Func） —— 对无返回值、使用Action或Func作为参数、多重载的方法进行单元测试》
5.《VS2012 Unit Test——Microsoft Fakes入门》
6.《VS2012 Unit Test —— 我对IdleTest库动的大手术以及对Xml相关操作进行测试的方式》
插曲：前段时间与某个公司的开发经理（反正是管理开发的）聊过，问我最近在搞什么技术，答曰小酌单元测试，其反问”要改当测试人员了啊“。由此可见还是很多做开发的误以为单元测试应由测试人员来做，单元测试应该是100%由开发人员完成，甚至我们码农还要编写集成测试代码。
单元测试只是TDD的一部分，其他的例如还有集成测试等。而TDD不但是编码的事，还是测试的事，更是设计的事，即为整个项目团队的事，所以绝对不是说用就用的，我这也算是发发牢骚罢了，发完还是要回头去干改bug的活。
以下摘自《C#测试驱动开发》。
TDD优点（简言之就是使设计更佳，缺陷更少）：
1.一开始就保证代码的质量；
2.使开发人员更遵循SOLID原则；
3.确保代码与业务需求之间的高度一致性；
4.TDD鼓励创建更简单、针对性更强的库和API；
5.鼓励与业务用户多沟通；
6.有助于从系统中清除那些没有用到的代码；
7.提供了内置回归测试；
8.终止了递归错误的出现
9.可以得到开放的、可扩展的、灵活的体系结构。
单元测试框架：NUnit、MSTest（上述文中所用的）、MbUnit、xUnit。
模拟框架：Fakes（MSTest的模拟框架）、Moq、Rhino Mocks、Type Mock
依赖注入框架：Structure Map、Unity、Windsor、Autofac
能力有限，错漏难免，欢迎批评指正！！
参考资料：MSDN、C#测试驱动开发（Professional Test Driven Development with C#）