用途：在开发新功能或修复缺陷时按测试驱动开发（TDD）的红-绿-重构循环推进，先写测试再写实现。
核心理念：测试应通过公共接口验证行为，而非实现细节；代码可整体重写，测试无需改动。好测试读起来像规格说明，描述系统做什么而非怎么做，能经受内部重构。反面信号包括：mock 内部协作者、测试私有方法、断言调用次数/顺序、重构后行为未变测试却失败、测试名描述怎么做而非做什么。
.mock 边界：仅在外部 API、数据库（有时，优先用测试数据库）、时间/随机数、文件系统（有时）处 mock；不要 mock 自己控制的类、模块或内部协作者。推荐依赖注入（把外部依赖作为参数传入），并采用 SDK 风格接口（每个外部操作一个函数），便于独立 mock。
设计可测试性：接收依赖而非内部创建；返回结果而非产生副作用；缩小接口面（更少方法、更少参数）；追求深模块（小接口+大量实现）。
反模式：横向切片，即先一次性写全部测试再一次性写全部实现。正确做法是垂直切片/曳光弹：一个测试→一个实现→重复。
工作流：1) 规划——与用户确认接口变更、优先测试哪些行为、设计可测试接口、列出要测试的行为并获批准；2) 曳光弹——写一个测试确认一件事，RED 确认正确失败，GREEN 写最小代码确认通过；测试立即通过说明在测已有行为，需修正测试；测试报错而非断言失败，先修错误；3) 增量循环——每次一个测试，只写足够通过当前测试的代码，不预判未来测试；4) 重构——全部通过后再重构，抽取重复、深化模块、应用 SOLID，每步后运行测试；RED 状态下绝不重构。
每轮检查单：测试描述行为而非实现；只用公共接口；能经受内部重构；代码对当前测试最小；无投机功能；写代码前观察测试失败；失败原因符合预期；其他测试仍通过。
缺陷修复：先写一个复现缺陷的测试（示例：空邮箱应被验证拒绝），RED 确认失败，GREEN 补最小检查使其通过，并确认其他验证测试仍通过。
类型测试：编译期类型断言，无运行时，用 bun typecheck 检查泛型、条件类型与类型约束回归。适用于泛型 API、工具类型、复杂推断、映射/条件类型、确保非法用法报错；不适用于字符串属性接收字符串之类的琐碎场景。需查找导出 Expect 与 Equal 的文件，没有则创建；Expect<T extends true> 编译错误即测试失败；Equal<X,Y> 做精确类型相等；Not、IsAny、IsNever 处理边界情况。负向测试用 @ts-expect-error，必须紧邻出错行并注明原因；未使用的指令视为测试失败。可用 declare const 声明无运行时的 mock 值，或用 type _name = Expect<...> 做仅类型层断言。运行 bun typecheck，编译通过即测试通过。
限制：资料未提供安装命令、平台要求、收费或价格信息，暂未提供。