快照测试驱动开发 (STDD)
快照测试驱动开发是**快照测试**和**测试驱动开发**的结合。
当正统测试驱动开发不起作用时，它通常是一种理想的方法。
流程
开发人员编写一个测试来设置一个场景，该场景应该*产生预期结果，但没有在测试中定义结果。
这个场景可能是“登录，点击报表链接，报表出现”。
然后，他们在**正常模式**下运行**失败的测试** - 验证它是否正确设置了场景。
然后他们在**重写模式**下运行测试 - 根据程序的行为调整结果。例如，对新仪表板进行截图或将文本输出保存到测试中。
然后，开发人员调整代码，查看结果，只有在他们对结果满意后才提交代码 - 例如，仪表板看起来正确。
未来的普通测试运行（例如在 CI 上）将比较快照与实际输出，如果任何内容发生变化则会失败。
示例
以下是用 hitchstory 构建的四个示例项目，所有项目都设置为进行快照测试驱动开发
-
命令行 - 交互式命令行测试中的截图步骤验证命令行“截图”，该截图将在重写模式下被重写。
-
REST API - 在重写模式下，当代码更改时，REST API 的响应会被重写。
-
网站 - “expect”步骤中的输出将在重写模式下被重写。例如，在错误标签中期望“错误消息”，并且会比较截图。
-
Python API - 这些测试中会捕获 print 语句的结果，并且可以被重写。
何时进行？
正统单元测试驱动开发对于一组特定的情况非常有效 - 也许甚至更具体
- 输出清晰且相对简单，并且你确切地知道它们应该是什么，例如计算结果。
- 输入清晰且相对简单。
- 代码是无状态且函数式的。
但并非所有开发都是这样的。对于开发人员来说，以下情况非常常见 - 也许甚至更常见
- 对场景有清晰的认识。
- 对输出应该是什么有一个模糊的概念。
- 但是为了让他们在看到时清楚地了解他们的需求。
在这种情况下，快照测试驱动开发非常有效。
集成测试与单元测试
快照测试驱动开发通常更适合进行集成测试的场景。