加载完测试夹具后，我编写了一些测试来探查它的一些特性。但在实际应用中，该夹具可能会被频繁更新，因为用户可能在界面上修改数值。 大多数更新都是通过设值函数完成的，我一般也不会测试这些方法，因为它们不太可能出什么bug。不过`Producer`类中的产量（production）字段，其设值函数行为比较复杂，我觉得它倒是值得一测。 ##### describe('province'... ``` it('change production', function() { 　　asia.producers[0].production = 20; 　　expect(asia.shortfall).equal(-6); 　　expect(asia.profit).equal(292); }); ``` 这是一个常见的测试模式。我拿到`beforeEach`**配置**好的初始标准夹具，然后对该夹具进行必要的**检查**，最后**验证**它是否表现出我期望的行为。如果你读过测试相关的资料，就会经常听到各种类似的术语，比如配置-检查-验证（setup-exercise-verify）、given-when-then或者准备-行为-断言（arrange-act-assert）等。有时你能在一个测试里见到所有的步骤，有时那些早期的公用阶段会被提到一些标准的配置步骤里，诸如`beforeEach`等。 > （其实还有第四个阶段，只是不那么明显，一般很少提及，那就是**拆除阶段**。此阶段可将测试夹具移除，以确保不同测试之间不会产生交互。因为我是在`beforeEach`中配置好数据的，所以测试框架会默认在不同的测试间将我的测试夹具移除，相当于我自动享受了拆除阶段带来的便利。多数测试文献的作者对拆除阶段一笔带过，这可以理解，因为多数时候我们可以忽略它。但有时因为创建缓慢等原因，我们会在不同的测试间共享测试夹具，此时，显式地声明一个拆除操作就是很重要的。） 在这个测试中，我在一个`it`语句里验证了两个不同的特性。作为一个基本规则，一个`it`语句中最好只有一个验证语句，否则测试可能在进行第一个验证时就失败，这通常会掩盖一些重要的错误信息，不利于你了解测试失败的原因。不过，在上面的场景中，我觉得两个断言本身关系非常紧密，写在同一个测试中问题不大。如果稍后需要将它们分离到不同的`it`语句中，我可以到时再做。