相信大家从小就被千叮万嘱要做单元测试。然后秉承这一信念，成为了一个测试狂魔。凡有代码，测！覆盖！最终，一波操作猛如虎：467测试，0错误，0自信。
第二天。
你为了优化，颤抖着手更改了一行代码。果不其然发现牵连了1e9个测试用例，测试结果瞬间变成满江红。
你开始怀疑自己，单元测试到底为了什么？除了增加大量工作量以外，好像没什么好处？
从此你与单元测试势不两立…………先等等！
如果你有这样的疑问，说明两个问题：
在说“测什么”的时候，先解决比较简单的“怎么测”问题。
没错，反直觉的是“怎么测”比“测什么”更加简单……
单元测试野路子不多，老师教的理论也无非只有两种：白盒测试、黑盒测试。
那么我们应该选择哪种？
太长不看：黑盒测试
从现在开始可以忘掉白盒测试这个名词了……这个东西在工程上根本不实际。
你给我等等，你一句话就把代码覆盖率说的一文不值？
其实我也没说代码覆盖率没用，我只是纯diss白盒测试。
“高代码测试覆盖率”是“代码质量高”的必要不充分条件。
白盒测试为了跑高代码覆盖率，追求走遍代码的每一个角落。
嗯。是。代码覆盖率是很高了。然后呢？这些用例意义的目的是什么？
目的仅仅是为了得到一个高覆盖率吗？
目标仅仅是刷kpi没事找事吗？
它到底验证了什么问题？
好好好，让我们祈祷这位程序员可以保持这种劲头
因为当代码重构后，可难免重新再做一轮白盒测试咯~
说到底，测试测的是软件行为，而不是代码结构。
好的测试应该在代码内部重构（行为不变）时保持不变。利益相关者、终端用户在乎的也只有软件的行为，软件内部的实现真的没人会管；而如果测试依赖于代码结构，那重构时改变了代码结构，测试也需要连带改动。
所以这不就说明，应该要用黑盒测试取代白盒测试吗？
那么又该使用什么流程进行单元测试？
黑盒测试本身是很简单：给定输入，验证输出即可。
但测试目标不仅是测试通过，还应是能让大伙一目了然的知道测试干的是什么，被测试的函数又干的是什么。
为此，我建议：
例子：
测试一个函数，其作用是执行一个加法。
public int Addition(int a, int b) => a + b;
现在测试该函数是否正常运作。
using Xunit;
[Theory]
[InlineData(1, 1, 2)]
[InlineData(-1, 1, 0)]
public void GivenTwoAddends_WhenAddition_ShouldReturnAddedValue(int addend1, int addend2, int answer)
{
// Given
// Two addends (in parameters this case)
// When
var result = Addition(addend1, addend2);
// Then
Assert.Equal(answer, result);
}
虽然代码是C#的，但道理是相通的。
如果测试中涉及到其它依赖项怎么办？
由于单元测试只关注目前单元的表现，单元外的逻辑（即依赖项）一律视为无关项。
对于无关项，我们不关注它是否正确执行，而是假定它正确执行
因此我们可以通过Mock等手段，模拟外部依赖项，让其直接返回一个预定的结果。
当然，为了更好地使用Mock，我们需要将外部依赖项注入到待测试的模块中。
在 ASP.NET Core 中，一般实现为构造函数注入。
也就是我们需要将模块修改成依赖注入的形式。它使用到了Magic，在构造函数中注入：
public class MysteryAddition
{
private readonly Magic magic;
public MysteryAddition(Magic magic) => this.magic = magic;
/// <summary>
/// Return a + b if not magic. Return random non-negative otherwise.
/// </summary>
public int Addition(int a, int b)
{
if (magic.DoMagic())
{
return new Random().Next();
}
return a + b;
}
}
该函数的定义是：当Addition函数被施加了某种魔法时，返回一个随机非负整数；否则返回a+b的结果。
这个模块使用的外部依赖Magic，形式如下：
public class Magic
{
public bool DoMagic()
{
// This is a very complicated magic function
// Omit 100000 lines
// And pretend that it returns something.
return true;
}
}
我们是需要对MysteryAddition.Addition函数进行单元测试。根据其定义，会有两个分支情况，而且返回的逻辑不同。
因此我们会写出两个用例。每个用例都会使用假的Magic，并且假定它的不同情况：
using Moq;
using Xunit;
[Theory]
[InlineData(1, 1, 2)]
[InlineData(-1, 1, 0)]
public void GivenTwoAddends_WhenAdditionWithoutMagic_ShouldReturnAddedValue(int addend1, int addend2, int answer)
{
// Given
// Two addends (in parameters this case) and ...
// Setup mocked magic.
var magic = new Mock<Magic>();
magic.Setup(x => x.DoMagic()).Returns(false); // No magic :(
var service = new MysteryAddition(magic.Object);
// When
var result = service.Addition(addend1, addend2);
// Then
Assert.Equal(answer, result);
}
[Theory]
[InlineData(1, 1)]
[InlineData(-1, 1)]
public void GivenTwoAddends_WhenAdditionWithMagic_ShouldReturnNotNegativeValue(int addend1, int addend2)
{
// Given
var magic = new Mock<Magic>();
magic.Setup(x => x.DoMagic()).Returns(true); // Let's be magical!!!
var service = new MysteryAddition(magic.Object);
// When
var result = service.Addition(addend1, addend2);
// Then
Assert.True(result >= 0);
}
不难看出，我们所断言的只有函数的行为，用例完全由函数的定义进行编写。
该过程既不考虑其它模块的正确性/干扰，也不涉及函数内部的实现。
就算我不给你Addition的代码，你也可以通过定义写出测试用例。
Mock很好用吧？它可以模拟依赖，化繁为简
但是小心，成也Mock，败也Mock……
你有没有发现，如果引入了Mock，你还需要知道这个被模拟的依赖项在函数中起到了什么作用。
黑盒似乎变得的没那么黑了？
而且更恐怖的是……
好，当我使用黑盒测试的原则编写了结构无关的用例后，感觉上好多了……
但感觉还是很痛苦！每次测试我都要Mock一大堆依赖项！
这是因为你测试了一切，这是单元测试最大的痛苦来源。
有些东西它本身就不适合被单元测试……
说到底，只应编写高性价比的单元测试。
进行单元测试之前，我们应该进行权衡：
如果你要测的模块跟上节提及的Addition函数一样简单，那没什么好说的，30秒写完，性价比爆高！
但如果你面对一个意大利面一样的厚礼蟹代码模块
首先，你扪心自问：测吗？
那还用问？肯定不测。
然后，你再扪心自问：你写出这样的代码真的好吗？
……
……
……
你犹豫了，因为你发现有时候单元测试难写的原因不在于单元测试本身，而是因为被测试的代码太烂了！
但庆幸的是，这也是单元测试给你带来的“正面副作用”之一。
有没有发现，当你考虑是否进行单元测试的同时，你也在审视自己的代码。当你发现代码非常难测试的时候，可能就是一个代码质量低的警告。你可能没有遵循单一职责原则。你的万能函数做了太多事情。
所以怎么办？
重构你的代码。
将你的万能函数，万能类，一步步分割为更小的模块。
最终你将一个万能类A，分成了4个类：
A +-- B
+-- C
+-- D
没错，此时A成为了B、C、D三个功能模块的协调者。由于B、C、D现在都仅有一个单一职责。你现在可以很轻松地对他们分别进行单元测试。性价比爆高！测爆！
好好好，B、C、D是解决了……
那协调者A本身呢？我还要对它进行单元测试吗？
是否对协调者A进行单元测试，还是取决于性价比。但我劝你谨慎，因为：
对A进行单元测试，需要解决B、C、D三个依赖项负担。如果你重构代码时对B、C、D动刀了，那也意味着你可能需要修改测试用例的Mock B、C、D行为。
哥们衡量单元测试的效益不仅仅是工作量、维护性的问题，还得关注这个模块本身到底重不重要。
比如：这是一个支付模块，要是出错可能要赔几十个，甚至牢底坐穿。
那你说测不测嘛，肯定得测咯！
当遇到难以测试的问题时，第一步先别责怪单元测试本身。而是问问自己，这个代码单元能不能再细分、结构优化。
当你确定已经没有优化的余地了，但感觉还是难以测试，考虑性价比：
思考这三个问题，自然有答案。
不要忘了，即使不单元测试，你还是会（至少应该！）编写包含该模块的集成测试来确保它正常运行。
但如果你问我的想法，经历了这段时间的捣鼓，我会回答：
不不不，我大概率不会对这种东西进行单元测试。
从另一个角度看待问题。
当我确定要对这个模块进行单元测试了，我应该测它的啥？
第一节中说要进行黑盒测试。那我们就将系统看作一个黑盒，即一个一般化的物体。
我们说要测试行为，其实就是测试黑盒物体与外界的交互行为。
而行为的媒介即消息。
物体与外部的交互，可以视为消息的传达与回复。
所以整个问题变成了：我们需要针对什么消息进行单元测试？
在此之前，先看看消息本身到底是什么：
这个物体跟外界的沟通只有两个方向：入向消息，出向消息。
此外，物体还会有内部消息流向。
如果你要我当一次灵魂画师，我会画出下面这样的图😀：
┏━━━━━━━━┓
--[in]--> ┃ object ┃ --[out]-->
┗━━━━━━━━┛
↓-[self]-↑
从函数的角度来讲：
消息本身分为两类：查询（Query）和命令（Command）
Addition加法函数当然，也存在同时为查询和命令的操作，比如Stack.Pop()
虽然如此，我们还是可以按消息的类别考察某种消息是否需要被测试。
已知：
好，我们直接做一个笛卡尔积，得到6种组合。
这些组合有些是需要测试的，有些是无需测试的。
魔法师Sandi Metz曾发表过一次演讲The Magic Tricks of Testing，讲述了如何理解这6种组合在测试中的含义。
有兴趣的可以观看上面的演讲，实在受益匪浅。
我这里就不卖关子，直接剧透6种消息组合的测试操作：
| Message | Query | Command |
|---|---|---|
| In | 1.a 检测结果 | 1.b 检测直接公共副作用 |
| Self | 2.a 不要测试 | 2.b 不要测试 |
| Out | 3.a 不要测试 | 3.b 确保消息送出 |
直接检测调用结果。
这就是我们第一节中测试Addition的情景
检测它的直接影响（副作用）。
最简单地，比如一个属性，有getter和setter：
public class Number
{
private int num;
public int Get() => num;
public void Set(int num) => this.num = num;
}
只是显式举个例子，C#千万别这么写。写Property拉！
我们需要单元测试setter，那我们可以调用setter，然后使用getter检测它是否正常运作。
你为什么需要测试它？
到底有谁在关注它？
如果外部消息行为正确，其实已经保证内部调用也正确了，所以有了上一步，这一步是冗余的。
a: 调用一个外部查询
这不就是我们第一节的第二个例子吗？
外部依赖项Magic被MysteryAddition调用了。
我们站在MysteryAddition模块的角度，这就是一个出向消息。我们需要对这个消息，即Magic.DoMagic()的行为进行验证吗？
没有吧。我们要单元测试的是MysteryAddition，Magic正不正确，关我什么事喔，你去找他咯。
但还没完，回顾那个例子
我们要让代码执行下去以测试入向信息啊
所以遇到这种情况，我们虽然不测试出向消息，但如果我们需要单元测试继续执行下去，需要模拟这个消息的返回。比如我们在上面，使用Mock返回了假的结果。
值得一提的是，生成测试替身（Test Double）的方式不只有Mock一种。
但话说到底，这种Mock仍然是十分不自然的。如果你发现设置Mock的难度非常大，建议还是遵循之前说的性价比原则：
模块细分到极致
放弃单元保明智
b: 调用一个外部命令
这种情况我们不能摆烂，我们需要确保命令信息成功送出了。
有人会有疑问：
啊？为什么？为什么要管外部依赖的状态！
但仔细想想，这其实并不是在检测外部依赖的状态，而是检测当前单元与外部依赖的衔接性。
我们单元的行为就是：当执行成功时，需要向外部依赖传出一个消息。
所以我们并没有脱离这个单元的范畴。
比如，你要测试一个发送注册邮件的函数SendVerificationEmail，它经过处理之后，最终会调用邮件服务（一个外部依赖）发送邮件。
那么问题来了：
SendVerificationEmail函数并没有返回结果那怎么知道SendVerificationEmail真的正常工作？
你说得对，在单元测试的范畴，我们没办法100%确保它正常工作。
但我们至少可以确定一个预估行为：代码应调用了邮件服务。
假设我们的外部邮件服务的接口是：
public interface IEmail
{
public void Send(string address, string content);
}
我们需要单元测试的是：
public class EmailMessenger
{
private readonly IEmail email;
public EmailMessenger(IEmail email) => this.email = email;
public void SendVerificationEmail(int userId)
{
var address = $"{userId}@yourdomain.com";
var content = $"Hello, {userId} ...";
// ... more processes.
email.Send(address, content);
}
}
我们就需要验证IEmail.Send仅被调用一次
[Fact]
public void GivenUserId_WhenSendVerificationEmail_ShouldReallySendIt()
{
// Given
var userId = 1;
var email = new Mock<IEmail>();
email.Setup(x => x.Send(It.IsAny<string>(), It.IsAny<string>()));
var service = new EmailMessenger(email.Object);
// When
service.SendVerificationEmail(userId);
// Then
email.Verify(mock => mock.Send(It.IsAny<string>(), It.IsAny<string>()), Times.Once());
}
从单元的角度，消息的流向有3个方向。
其中我们只需要单元测试入向与出向消息。
说实话，单元测试绝对是一个被低估的大魔王
它给人的感觉非常和善，人畜无害
但实际上笑里藏刀
打败这个大魔王的奖励非常丰厚，它可以带给我们：时间、效率、收益
但是，他没那么容易被打败
希望这篇文章成为你打败它的究极魔咒（）
师傅别念了
不仅仅是参考资料。如果你有时间，我建议你也阅读这些资料。
如果你在想下面这些MVC中的层次是否需要单元测试，可以从上面的资料获得答案。
长话短说：
Repository：直接集成测试，不要单元测试Controller：直接集成测试，不要单元测试Service：是否单元测试取决于该服务是否独立，依赖项是否少，性价比是否高