该技能是一条关于测试编写方式的原则，核心主张是：测试应当像用户那样调用代码，并断言用户看到的确切结果，而不是断言实现细节。
用途 它用于在编写、修改或保留测试时提供判断标准。资料给出的检验方法是：如果一个测试在被导入的每个函数都返回 undefined 或错误值时仍然能通过，那么这个测试就应当被重写或删除。
不合格的测试形态 资料明确列出以下几类会通不过上述检验的写法：
- 断言过松或没有断言：toBeDefined、toBeTruthy、not.toThrow、toBeGreaterThan(0)。
- 只检查调用或缺失：toHaveBeenCalled、not.toHaveBeenCalled、toBeUndefined、toEqual([])。
- 期望值由被测代码自身计算：expect(f(a)).toBe(f(a))。
- 复述常量、配置默认值、表格行或提示字符串。
- 对测试自己构建的数据做断言，而没有调用被测对象。
修复方式 资料给出的修复办法是：在测试体内用具体输入调用被测对象，并断言字面输出或效果。对于 mock，断言它收到的载荷。对于缺失场景，还要在另一个输入上断言存在。对于常量，改为用一个输入测试读取该常量的机制，而不是复述该值。
保留的例外 资料也说明了几种应当保留的情况：跨表格行的关系检查（例如某个键出现在两张表中、某个父项存在）；*.test-d.ts 类型检查；当契约要求缺失、且让被测对象产生该缺失会导致测试失败时的仅缺失测试（例如被拒绝的操作必须不发送邮件，可临时让被拒绝路径发送一封邮件并观察测试失败）；以及当常量值是对用户的承诺（例如文档化的默认值）时的常量固定，并需要为该承诺命名。
适用场景与限制 该原则适用于测试的编写、修改与保留决策，尤其针对单元测试中常见的弱断言与实现耦合问题。资料未提供具体语言、框架、安装方式或平台信息，也未说明收费、价格或效果数据，这些内容暂未提供。