绝大部分软件都是由多人合作完成的，大家的工作相互有依赖关系。某人负责的模块的功能被其他人调用，但如何让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？？？单元测试就是一个很有效的解决方案。
创建单元测试函数的主要步骤是：
1.设置数据（一个假象的正确的E-mail地址）
2.使用被测试类型的功能（用E-mail地址来创建一个User类的实体）
3.比较实际结果和预期的结果（Assert.IsTrue(target!=null）
创建完就可以运行单元测试了，同时可以看看代码覆盖报告，代码百分百地都被覆盖了。
怎样才算一个好的单元测试呢？单元测试应该准确、快速地保证程序基本模块的正确性。
验证单元测试好坏的一系列标准：
1.单元测试应该在最基本的功能、参数上验证程序的正确性；
2.单元测试必须由最熟悉代码的人（程序的作者）来写；最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，保障语义的准确性。
3.单元测试过后，机器状态保持不变；这样就能不断地运行单元测试。
4.单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）；快才能保证效率
5.单元测试应该产生可重复、一致的结果；
6.独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性；
7.单元测试应该覆盖所有代码路径，包括错误处理路径；（要注意：100%的代码覆盖率并不等同于100%的正确性）
8.单元测试应该集成到自动测试的框架中；把单元测试自动化，这样每个人都能随时随地运行单元测试。
9.单元测试必须和产品代码一起保存和维护；
在单元测试的基础上，建立关于这一模块的回归测试（Regression Test）
针对一个Bug Fix，我们也要做Regression Test。目的是1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能，有没有Regression
回归测试中的回归可以将其理解为“回归到以前不正常的状态”
回归测试最好要自动化，这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。
VSTS提供了方便的效能分析工具，让我们能很快地找到程序的效能瓶颈，从而能有的放矢，改进程序。
效能分析可以选择两种分析方法：
1.抽样（Sampling）优点：不需改动程序，运行较快，可以很快找到瓶颈，缺点：不能得出精确的数据，也不能准确表示代码中的调用关系树
2.代码注入（Instrumentation）缺点是程序的运行时间会大大加长，还会产生很大的数据文件，相应的增加了数据分析的时间，同时注入的代码也影响了程序真实的运行情况。
一般的做法是先用抽样的方法找到效能瓶颈所在，然后对待定的模块用代码注入的方法进行详细分析。
看个人项目耗时对比记录表，显然，从学生到职业程序员，并不是更加没完没了的写程序——花在写代码上的时间反而少了许多。
实践是理论的基础和验证标准
实践最简单的项目：WC，根据书上项目要求，实现一个统计程序
如何保证质量——回归测试
如何为这个程序做有效的测试，有以下几种方法，自动化程序由低到高。
1.手动测试，手工比较
2.要做到不断地测试，可以把WC的主要功能封装成一个类，然后测试程序员调用这一个类的主要函数，得出结果并与标准作比较。
3.更进一步，比较测试的输出和标注结果
4.再进一步，把自动构建脚本和构建验证测试结合起来。记录出现的bug。
我看完认为第二章主要讲的是 在设计的时候就写好单元测试，保证程序基本模块的正确性；在单元测试的基础上，建立模块的回归测试，保证之前所有已经发现并修复的bug的确得到了修复，并没有在最后一个版本中复发，才能保证尽早发现问题。还有对程序的效能分析，提高效能，优化程序。