• 契约测试与功能测试之间的区别(又名怎样做契约测试才不会陷入令人抓狂的误区)

    契约测试与功能测试之间的区别(又名怎样做契约测试才不会陷入令人抓狂的误区)

    对于刚开始正式接触契约测试的团队,对于契约测试和功能测试之间的区别经常会存在争论。难就难在其实并不存在什么非黑即白的答案,更为重要的应该是逐渐加深对契约测试的理解和使用。

    使用契约测试常见的场景,是验证规则或者处理错误请求。例如,我们有一个用户服务,允许消费者使用POST请求注册新用户,并在HTTP Body中包含所创建用户的详细信息。

    一个简单的消费者与提供者交互的常规场景如下所示:

    1. Given "there is no user called Mary"
    2. When "creating a user with username Mary"
    3. POST /users { "username": "mary", email: "...", ... }
    4. Then
    5. Expected Response is 200 OK

    如果只验证常规场景,则会遗漏不同响应的其他场景,并可能使消费者误解提供者的行为。所以,我们还需要验证失败的场景:

    1. Given "there is already a user called Mary"
    2. When "creating a user with username Mary"
    3. POST /users { "username": "mary", email: "...", ... }
    4. Then
    5. Expected Response is 409 Conflict

    可以看出,通过使用不同的响应代码,我们覆盖了一个新的错误场景验证。

    接下来,用户服务的团队告诉我们,用户名只允许包含字母,其最大长度不能超过20个字符,空白的用户名是无效的。那我们是不是应该在契约测试中加点东西呢?

    这会成为连锁反应的开始,很可能会向契约测试中添加3个场景,类似于这样:

    1. When "creating a user with a blank username"
    2. POST /users { "username": "", email: "...", ... }
    3. Then
    4. Expected Response is 400 Bad Request
    5. Expected Response body is { "error": "username cannot be blank" }
    1. When "creating a user with a username with 21 characters"
    2. POST /users { "username": "thisisalooongusername", email: "...", ... }
    3. Then
    4. Expected Response is 400 Bad Request
    5. Expected Response body is { "error": "username cannot be more than 20 characters" }
    1. When "creating a user with a username containing numbers"
    2. POST /users { "username": "us3rn4me", email: "...", ... }
    3. Then
    4. Expected Response is 400 Bad Request
    5. Expected Response body is { "error": "username can only contain letters" }

    到这一步为止我们其实已经滥用了契约测试,我们实际上是在测试用户服务是否正确实现了校验规则:而这实际上是功能测试,应该在用户服务自己的代码库中所覆盖。

    可是这有什么坏处呢……多测试些东西,不是挺好么?问题在于这些场景被过度设计,从而产生了不必要的紧耦合契约。如果用户服务团队更改主意,觉得20个字符对用户名来说过于严格,并将这个限制增加到50个字符,该如何处理?如果用户名允许使用数字了,又该如何处理?理论上任何消费者都不应受到任何这类变更的影响,但不幸的是,仅仅放宽了一点验证规则,用户服务就会破坏Pact契约。这其实并不是什么破坏性的修改,但是由于我们对场景的过度设计,阻碍了用户服务团队对新需求的实现。

    所以,回到之前的场景,我们换成只是验证用户服务对输入错误的响应:

    1. Given that username "bad_username" is invalid
    2. When "creating a user with an invalid username"
    3. POST /users { "username": "bad_username", ... }
    4. Then
    5. Response is 400 Bad Request
    6. Response body is { "error": "<any string>" }

    只做了一点修改,但看起来更灵活了!现在用户服务的团队可以改变他们的验证规则,而不会破坏我们的契约……

    我们其实并不关心用户名最大长度是多少,或允许使用什么类型的字符,我们只关心如果消费者发送的请求不合法时,用户服务是怎样响应的。

    在编写契约测试的交互时,应该明确测试想要覆盖的内容。契约能够帮助我们捕捉到以下这些问题:

    • 消费者中的缺陷
    • 从消费者角度对于接口使用的理解是否存在偏差
    • 提供者对接口的破坏性变更
      简而言之,契约场景不应该深入到提供者的业务逻辑细节,而应该专注于验证消费者和提供者是否对请求和响应达成共识。在我们的示例中,所写的场景更关注于验证是怎样失败的,而不是验证为何失败。