测试替身

要性，也在想方设法减少这些测试。

1. 如果一个测试可以在最底层写，那么就不要在他的上一层写了，因为他的运行速

度更快。

参考书籍:

•《优质代码——软件测试的原则、实践与模式》 •《Python Web 开发：测试驱动开发方法》

测试替身

测试替身（Test Double）是一个非常有意思的概念。

有时候对被测系统(SUT)进行测试是很困难的，因为它依赖于其他无法在测试环境中使用的组件。这有可能是因为这些组件不可用，它们不会返回测试

所需要的结果，或者执行它们会有不良副作用。在其他情况下，我们的测试策略要求对被测系统的内部行为有更多控制或更多可见性。如果在编写测试

时无法使用（或选择不使用）实际的依赖组件(DOC)，可以用测试替身来代替。测试替身不需要和真正的依赖组件有完全一样的的行为方式；他只需要

提供和真正的组件同样的 API 即可，这样被测系统就会以为它是真正的组件！——Gerard Meszaros

当我们遇到一些难以测试的方法、行为的时候，我们就一些特别的方式来帮助我们测试。Mock 和 Stub 就是常见的两种方式：

1. Stub 是一种状态确认，它用简单的行为来替换复杂的行为
2. Mock 是一种行为确认，它用于模拟其行为

通俗地来说：Stub 从某种程度上来说，会返回我们一个特定的结果，用代码替换来方法；而 Mock 只是确保这个方法被调用。

Stub

Stub 从字面意义上来说是存根，存根可以理解为我们保留了一些预留的结果。这个时候我们相当于构建了这样一个特殊的测试场景，用于替换诸如网络或者 IO 又调度等

高度不可预期的测试。如当我们需要去验证某个API被调用并返回了一个结果，举例在最小物联网系统设计中返回的 json，我们可以在本地构建一个