最好有一些预备知识，例如xUnit，Moq，如何编写易于测试的代码，这些内容我都写了文章：https://www.cnblogs.com/cgzl/p/9178672.html#test。
Test Driven Development
什么是TDD（Test Driven Development）?
TDD是一个软件开发过程，这个过程依赖于重复性的小开发周期：需求被转化为具体的测试用例，然后改进程序以便通过测试。
在TDD里有两条规则：
只在有未通过的自动化测试的情况下，你才会去写新的代码
消灭重复
这两条规则在技术上的含义是：
你必须进行良好的设计，运行的代码可在决策之间提供反馈
开发人员得写自己的测试
开发环境可以针对微小的变化需要提供快速的响应
您的设计必须由众多高内聚、低耦合的组件组成，这样测试会更简单。
这两条规则也意味着编程的三个任务：
Red - 先写一个不能工作/通过的小测试，甚至根本无法编译
Green - 快速让这个测试通过，无论代码有多烂
Refactor - 消除上个步骤中的代码重复。
Red，Green，Refactor，这就是TDD的咒语。
如果TDD可以很好的执行，那么它就会大幅度减少代码缺陷的密度，也使工作的主题对于相关人员来说更加清晰。所以，TDD也具有社会含义：
如果缺陷密度可以降低到足够的程度，那么QA就会从被动变为主动的工作。
如果那些“让人讨厌的惊喜”可以减少到足够的程度，那么项目经理就可以精确的评估以便让客户参与到每日的开发工作中。
如果技术会议的主题足够清晰，那么程序员就会按分钟去工作而不是按天或周来安排和进行工作。
如果缺陷密度可以降低到足够的程度，那么我们每天都可以交付出具有新功能的软件，这就会与客户建立新的业务关系。
这些概念都很简单，但是动机是什么？为什么开发人员要去写自动测试代码？为什么开发人员在他们的思维能够大幅飙升的设计时，却只进行小步工作？ 勇气。
勇气
TDD是编程过程中管理恐惧的一种办法。
这个恐惧不是坏事，它是一种合理的恐惧，例如：”这个问题确实很难，我从开始的感觉看不到尽头“。
如果疼痛是喊停的自然表达，那么恐惧就是告诉你要“小心”。
小心是很好的，但是恐惧还有一些其它的影响：
让你不得不进行更多试探性操作
让你交流的更少
让你羞于反馈
让你脾气暴躁
这些影响在开发的时候对你都没有任何帮助，尤其是遇到困难问题的时候。那么你如何面对困难处境并且：
取代尝试/试探，而是尽快进行具体学习
取代争吵，而是进行更清楚的沟通
取代避免反馈，而是寻求帮助，和具体的反馈
控制你自己的脾气
TDD会管理这些事情。
为什么要TDD
从业务角度：
提供了需求的确认。通过编写测试以及RGR周期，需求确认很自然的在软件开发的过程中就完成了。
捕获回归问题。回归问题就是指随着软件新功能的发布，以前的某些功能却不好用了。TDD可以很早的发现回归问题。
综上两点，TDD也降低了维护成本。
从开发人员角度讲，TDD还有以下好处：
设计为先的心态。写测试的时候，我们就得考虑与软件的交互应该如何实现，以便把这些功能需求编程可能。
防止过度工程。关注于如何让测试通过和满足客户的期待，就会让我们保持正轨，而不是迷失于架构设计和幻想那么无法提供很多价值的最佳抽像设计中。
增加开发人员的动力。取代了花费几天时间想尽办法来实现某个功能这样的操作，TDD把需求分解成一些测试，并结合RGR流程，这就允许你可以持续快速的进展并建立成功循环。
收获自信。通过大量的测试结果，你感动支配的力量，无论修改、重构、增加功能都变得很简单。
第一个实例
在本例中，您将会看到TDD的如下步骤：
快速添加一个测试
运行所有的测试（包括以前写的），可以看到新添加的测试Fail了
修改一点代码
运行所有测试，都成功了
重构，移除重复
建立.NET Core 项目
这个很简单，首先建立一个Console App：
然后再添加一个xUnit项目：