XUnit 2.2.0 单元测试框架
xunit.runner.visualstudio 2.2.0 测试运行工具
Moq 4.7.10 模拟框架
为什么要编写单元测试对于为什么要编写单元测试，我想每个人都有着自己的理由。对于我个人来说，主要是为了方便修改（bug修复）而不引入新的问题。可以放心大胆的重构，我认为重构觉得是提高代码质量和提升个人编码能力的一个非常有用的方式。好比一幅名画一尊雕像，都是作者不断重绘不断打磨出来的，而优秀的代码也需要不断的重构。 当然好处不仅仅如此。TDD驱动，使代码更加注重接口，迫使代码减少耦合，使开发人员一开始就考虑面对各种情况编写代码，一定程度的保证的代码质量，通过测试方法使后续人员快速理解代码...等。 额，至于不写单元测试的原因也有很多。原因无非就两种：懒、不会。当然你还会找更多的理由的。
框架选型至于框架的选型。其实本人并不了解也没写过单元测试，这算是第一次真正接触吧。在不了解的情况下怎么选型呢？那就是看哪个最火、用的人多就选哪个。起码出了问题也容易同别人交流。
基本概念AAA逻辑顺序
准备（Arrange)对象，创建对象，进行必要的设置
操作（Act）对象
断言（Assert）某件事情是预期的。
Assert(断言)：对方法或属性的运行结果进行检测
Stub(测试存根\桩对象)：用返回指定结果的代码替换方法（去伪造一个方法,阻断对原来方法的调用，为了让测试对象可以正常的执行）
Mock(模拟对象)：一个带有期望方法被调用的存根（可深入的模拟对象之间的交互方式，如：调用了几次、在某种情况下是否会抛出异常。mock是一种功能丰富的stub） Stub和Mock的定义比较抽象不好理解，延伸阅读1、阅读2、阅读3
好的测试测试即文档
无限接近言简意赅的自然化语言
测试越简明越好，每个测试只关注一个点。
好的测试足够快,测试易于编写，减少依赖
好的测试应该相互隔离，不依赖于别的测试，不依赖于外部资源
可描述的命名：UnitOfWorkName_ScenarioUnderTest_ExpectedBehavior（命名可团队约定，我甚至觉得中文命名也没什么不可以的）
UnitOfWorkName 被测试的方法、一组方法或者一组类
Scenario 测试进行的假设条件，例如“登入失败”，“无效用户”或“密码正确”等
ExpectedBehavior 在测试场景指定的条件下，你对被测试方法行为的预期
基础实践“废话”说的够多了，下面撸起袖子开干吧。 下面开始准备工作：
vs2017新建一个空项目 UnitTestingDemo
新建类库 TestDemo （用于编写被测试的类）
新建类库 TestDemo.Tests （用于编写单元测试）
对类库 TestDemo.Tests 用nuget 安装XUnit 2.2.0、xunit.runner.visualstudio 2.2.0、Moq 4.7.10。
添加 TestDemo.Tests 对 TestDemo 的引用。
例：
public class Arithmetic { public int Add(int nb1, int nb2) { return nb1 + nb2; } }对应的单元测试：（需要导入using Xunit;命名空间。 ）
public class Arithmetic_Tests { [Fact]//需要在测试方法加上特性Fact public void Add_Ok() { Arithmetic arithmetic = new Arithmetic(); var sum = arithmetic.Add(1, 2); Assert.True(sum == 3);//断言验证 } }一个简单的测试写好了。由于我们使用的vs2017 它出了一个新的功能“Live Unit Testing”,我们可以启用它进行实时的测试。也就是我们编辑单元测试，然后保存的时候，它会自动生成自动测试，最后得出结果。
