为什么可重写测试驱动开发 (RTDD)？
可重写测试驱动开发是一种测试驱动开发形式，其中开发人员更改一些代码，在重写模式下运行测试，测试运行器会 *重写* 测试以匹配更改的输出。
示例
在上面的示例中
- 测试使用旧文本“待办事项列表”运行并通过。
- 代码经过调整，改为“我的待办事项列表”。
- 测试在正常模式下运行并失败。
- 测试在重写模式下运行并通过，并重写测试。
- 测试已更改，并在正常模式下运行时通过。
该视频还演示了如何调整引擎以使测试重写。
为什么要这样做？
使用这种技术可以节省大量时间。它使集成测试驱动开发变得有意义。
传统的测试驱动开发敦促你始终 首先构建测试，然后编写使测试通过的代码。
如果期望的输出一目了然，但构造起来很繁琐，那么这就会浪费时间。
最好编写生成输出的代码，让测试框架重写测试，并在提交它们之前手动检查重写的测试。
这种技术对于验证以下内容的集成测试特别有用：
- 命令行应用程序的输出（如上所示）。
- 网站上显示的包含上下文的精确错误消息。
- REST API 响应。
什么时候 *不* 使用它？
这种技术 *只能* 用于你可以一目了然地轻松验证输出是否正确的情况。
例如，对结果不明显的计算进行重写测试驱动开发是一种不好的反模式。
在哪里可以实际看到？
如果你查看 hitchstory 仓库，你可以尝试在三个带有集成测试的示例“待办事项”应用程序项目中自己尝试：