本人之前很少使用单元测试，总觉得平时的工作写得代码够多了，单元测试还要再编码，增加大量工作量，相信不少程序猿也是这么认为吧。
　　但是我认为，在必要的时候正确运用单元测试，可以大大缩短代码的调试时间，正所谓磨刀不误砍柴工，在此建议仍不会单元测试的，还是学一下吧。当然本人在单元测试方面还是菜鸟，无论是鸡蛋鲜花都欢迎。
　　近公司请微软的人做了一些关于使用VS2012进行单元测试的小培训，小生微做笔记，结合朦胧的记忆，在此自行总结，并分享之。废话少说，先上笔记：
　　1.先写单元测试（依我愚见，应该是接口先行，如果有的话）->测试失败->以小的改动（即编写实际代码）使测试通过（而在VS2012中已经不能通过现有项目直接生成测试项目了，我觉得这个功能还是应该保留，微软总是这副德行，强迫用户适应他们的产品，但是又不得不适应）；
　　2.不因单元测试而追加功能（代码），即逻辑不受单元测试影响；
　　3.改变了代码的逻辑（增删改），应及时运行单元测试；
　　4.在测试方法声明Attribute——TestCategory("分类或特征名");
　　5.在单元测试项目添加Fakes程序集分离外部依赖（如数据库访问，获取配置信息等）；
　　6.初始化单元测试类中的成员等信息，可添加方法并声明Attribute[TestInitialize]（方法需为public）；
　　7.测试自动化。
　　以下我将通过自己编写代码来验证上述笔记中的部分要点。有些未涉及，以后再尝试了。
　　1.新建一个单元测试项目，并添加类XmlSerializationTest，代码如下：
　　复制代码
　　[TestClass]
　　public class XmlSerializationTest
　　{
　　[TestMethod]
　　public void TestWriteXml()
　　{
　　UserInfo user=new UserInfo();
　　XmlSerialization serialization=new XmlSerialization();
　　bool flag=serialization.WriteXml<UserInifo>(user);
　　Assert.IsTrue(flag);
　　}
　　}
　　复制代码
　　由于我这个项目是对Xml序列化进行测试，因而前提是项目中已存在了一个UserModel类，并且在单元测试项目中添加相应引用
　　public class UserModel
　　{
　　public string LoginName{get;set;}
　　public string Password{get;set;}
　　}
　　接下来在编写实际的代码，微软讲师建议我们先在测试项目编写，待通过单元测试后再将代码移到相应的项目下面。
　　复制代码
　　public class XmlSerialization
　　{
　　public bool WriteXml<T>(T model)
　　{
　　throw new NotImplementedException();
　　}
　　}
　　复制代码
　　现在整个解决方案结构如下图所示

　　保证整个解决方案生成成功之后点击菜单“测试”-〉“运行”-〉“所有测试”，发现测试不通过，于是按照第一点笔记，以小改动使测试通过。
　　修改WriteXml方法为:
　　public bool WriteXml<T>(T model)
　　{
　　return true;
　　}
　　运行测试通过。对于返回值为bool的方法，个人建议进行至少两次Assert，也是分别对返回true和false进行Assert，因而我们再对WriteXml方法添加一个测试方法，
　　[TestMethod]
　　public void TestWriteXmlFalse()
　　{
　　Assert.IsFalse(new XmlSerialization().WriteXml<UserModel>(null));
　　}
　　运行测试，不通过，所以我得要好好改我的代码了，在改动当中坚持执行我的第三点笔记，改动代码及时运行单元测试。