由于很少编写程序，因此在TDD课程中通常会忽略编写规范（断言或测试假设）。
但是，它们非常重要。
他们确定如何编写和编写什么测试，还确定修复故障的难易程度。 他们几乎不需要时间来实施。 它们是第一个连接故事用户和代码的用户，并且第一个显示测试代码失败的用户。 它们也是可以保护我们免受测试代码本身错误的影响。
我们如何使我们的陈述更好？
首先，
规范应在术语上与用户故事相关 。 如果故事的用户使用术语“登录”，则assert不能更改此术语以进行身份验证/授权/验证。 如果故事写得不好，请进行更改。
其次，
规范必须明确包含它们描述
的组件的名称 。 如果鱼鹰突然间经常包含一些意外成分，则表示测试区域并发出错误信号。
有效脚本与“单一职责”原则很好地结合在一起，因此组件的名称必须与测试的描述相匹配。 如果存在许多有效方案，则该组件可能承担了太多责任。
同样，通常，一个场景描述ui事件或某种模式。 组件名称的合适候选者可以包含模式的名称：验证器，策略，构建器，变压器，控制器等。 或事件名称：Submitter，Login，ReadonlyOrderView等。 即 根据组件的名称，必须定义该类的主要功能的输入和输出值。 坏名：太抽象（服务，组件，帮助程序，实用程序）和双倍（ValidatorAndRenderer）。
第三，
规范必须明确说明条件 。
不好：
@Test public void testValidatePassword(){}
更好：
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
我们不必从另一个地方调用此函数，因此超长名称是有效的。 如果测试中的条件数量不合适，那么也许您应该更改组件的结构。
对于javascript测试相同的事情，但是您可以在其中放置条件，结果更加方便。
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
明确的条件更容易阅读和
发现缺失 。
此外，如果条件与书面测试代码不匹配，则该代码很容易纠正。
通常，一个好的描述是文档和代码注释的替代。 它是抽象的，它不依赖于框架和编译器，因此应与后两者同等对待。
条件本身必须在代码中保持一致以便于阅读，例如GIVEN-WHEN-THEN-SHOULD等。
第四，
规格应精简 。 以相反的顺序编写它们很有用：
错误优先，空值优先，路径幸福。 这样就无需在一个有效的用户案例之后完成测试。 对于UI组件：渲染，事件。 对于有状态组件，所有状态都是一致的。
因此，良好可读规范的结构如下所示：5-10个错误的一个有效脚本（或一个脚本的多个变体）
编写规范时，以文本形式完整编写规范是一种很好的做法，然后让您的同事阅读以明确和缺少条件。 然后，实际上，您已经可以开始编写实现了。 通常，以这种形式，任务是疏远的，即 好吧，当其他人编写测试实现时。
第五，
测试的
实现应与describe编写的内容相对应 。
优良作法是分为“布置-动作-声明”以轻松找到实现的一部分或另一部分的匹配项。 断言和异常的文本（如果存在）也应该与测试描述相关联，通常，我们可以简单地将它们重复。
不用说，在向测试中添加条件或断言时，您还需要更新测试说明。
因此，编写说明书的顺序可以如下。
- 阅读用户故事
- 名称组件和有效脚本
- 制定有效方案的条件
- 通过将错误的脚本放在顶部来补充规范
- 让邻居阅读并纠正丢失的内容
- 使用红绿重构循环一对一地实现测试和组件。