- 红灯、绿灯、重构
- KISS原则：keep it simple stupid (让前述规范得以通过，且最简单、最简短)
- 总之，未使用TDD的情况下，单元测试的主要目标是验证既有代码；而在TDD中，单元测试是预先编写的，其主要目标是定义需求和设计，而验证只是副产品。与实现后再编写测试相比，这样做的一个结果是产品质量更高
- 测试不仅提供了验证代码的途径，还是可执行的文档
- 学会不去测试最终结果，而专注于当前要开发的单元。这是为了加强信任，因为我们必须信任他人编写的代码（辅助类）
- 仅当所有测试都通过后才重构。这样做的优点如下：重构是安全的
- 设计——难以测试说明设计不佳
- 设计原则：YAGNI；DRY；KISS；奥卡姆剃刀原理；SOLID
- 逐个规范并实现单元；编写规范时，我们将除当前单元外的东西都隔离开来，并验证单元正确调用了其他单元
- BDD。将TDD应用于功能测试和集成测试
- TDD的好处之一是，可执行文档始终是最新的。然而，仅有通过单元测试获得的文档还不够。所以我们需要BDD
- 只要时间足够长，所有传统文档都将过时，唯一准确的文档是我们编写的代码
- 大多数情况下，其他文档指的是较简略的文档，如概述、系统的总体目标、使用的技术、环境搭建、安装、构建、打包以及其他类型的数据。它们不提供详细信息，更像是指南和快速入门。对于这些文档，markdown格式的简单README文件通常是最佳的
- BDD：可作为需求，可执行，可对工作进行验证，人人都能编写和理解
- 遗留代码就是不带测试的代码
- 遗留代码存在的一种常见坏味是无法测试
- 重构不能引入任何新功能，即不应编写任何新规范
- “基本类型偏执”坏味指的是使用基本数据类型表示域概念。例如，使用字符串表示消息，使用整数表示金额，使用结构体/字典/散列表示对象
- 总之，持续集成、持续交付和持续部署依赖于与实现代码配套的测试，即依赖于TDD，还要求不使用分支或确保分支的存活时间极短（被频繁地合并到主干）
- 请别忘了重构代码，删除不再使用的旧开关，让代码更整洁、可读性更高
网友评论