用途：指导如何编写有效测试并成功运行，适用于编写单元/集成/E2E 测试、调试测试失败、审查测试质量，以及决定何时 mock、何时使用真实实现。
测试分层：单元测试占 60-70%，仅在边界处 mock（数据库、API、文件系统、时间），内部协作者用真实实现；集成测试占 20-30%，使用真实数据库与缓存，只 mock 外部第三方服务（如 Stripe、SendGrid）；E2E 占 5-10%，不做任何 mock，使用真实服务（沙箱/测试模式）并进行真实浏览器自动化。
主要原则：测试行为而非实现；采用 Arrange-Act-Assert 结构；每个测试对应一个行为（验证同一逻辑结果时可多个断言）；使用描述性名称（如 it('rejects order when inventory insufficient')）；测试之间不共享可变状态。
运行顺序：lint/typecheck → 单元测试 → 集成测试 → E2E 测试，追求最快反馈前置。
调试失败：单元测试查看断言信息、检查 Arrange 设置、单独运行排除状态泄漏、加日志；集成测试检查数据库状态、mock 配置、竞态与事务/回滚；E2E 测试查看截图/视频、验证选择器、为异步操作添加显式等待、本地可见浏览器运行并对比 CI 环境。
Flaky 测试应积极处理：立即隔离到单独套件，一周内修复否则删除；常见成因包括共享状态、依赖时间、竞态与非确定性顺序。
覆盖率：质量优先，80% 有意义的覆盖优于 100% 琐碎覆盖，重点覆盖业务关键路径（支付、认证、核心领域逻辑），跳过生成代码。
边界用例应测试：最小值-1、最小值、最小值+1、最大值-1、最大值、最大值+1、零、一、多；特殊值如 null、空、负数、MAX_INT、NaN、unicode、闰年、时区；错误如网络失败、超时、非法输入、未授权。
反模式：过度 mock（测的是 mock）、测实现细节（重构即破坏）、共享状态（顺序影响结果）、测试重复（应改用参数化测试）。
限制：资料未提供具体测试框架版本、安装命令或完整代码示例，也未提供收费、价格与平台信息。