Testing Patterns 是一份关于测试模式与原则的系统性文档，目标是帮助开发者构建可靠的测试套件。它从测试金字塔出发，规定测试的层级结构：大量单元测试覆盖函数与类，适量集成测试覆盖 API 与数据库查询，少量端到端测试覆盖关键用户流程。
在具体写法上，文档推荐 AAA 模式：Arrange 准备测试数据，Act 执行被测代码，Assert 验证结果。选择测试类型时，单元测试适合纯函数和逻辑，速度最快（每个小于 100ms）；集成测试适合 API、数据库和服务，速度中等；端到端测试适合关键用户流程，速度最慢。
单元测试应遵循五项原则：快速（每个小于 100ms）、隔离（无外部依赖）、可重复（结果始终一致）、自校验（无需人工验证）、及时（与代码同步编写）。应测试业务逻辑、边界情况和错误处理，不应测试框架代码、第三方库和简单 getter。
集成测试关注 API 端点的请求/响应、数据库查询与事务、外部服务的契约。需要做好 setup 与 teardown：在所有测试前连接资源，每个测试前重置状态，每个测试后清理，所有测试后断开连接。
Mocking 的原则是：应模拟外部 API、数据库（单元测试时）、时间/随机、网络；不应模拟被测代码本身、简单依赖、纯函数和内存存储。模拟类型包括 Stub（返回固定值）、Spy（追踪调用）、Mock（设置期望）、Fake（简化实现）。
测试组织方面，命名可采用 should 行为、when 条件、given-when-then 等模式；使用 describe 对相关测试分组，it/test 表示单个用例，beforeEach 进行公共准备。测试数据可使用工厂生成、固件预定义、构建器流式创建，原则是使用真实数据、对非关键值随机化（如 faker）、共享公共固件、保持数据最小化。
最佳实践包括：每个测试一个断言以便清晰定位失败原因、测试相互独立不依赖顺序、保持快速以便频繁运行、命名具有描述性以实现自文档化、做好清理避免副作用。反模式则包括：测试实现而非行为、重复测试代码、复杂测试 setup、忽视不稳定测试、跳过清理。文档最后强调：测试即文档，如果他人无法从测试理解代码行为，就应重写测试。