断言那些事儿：单测只需要一个断言？

浅浅的花香味﹌ 2024-05-23 18:44 32阅读 0赞

![5ed80d7da6904639a76a02864c8beec2.png][]

[2024软件测试面试刷题，这个小程序（永久刷题），靠它快速找到工作了！（刷题APP的天花板）\_软件测试刷题小程序-CSDN博客文章浏览阅读3.4k次，点赞86次，收藏15次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题，web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题，还有互动交流板块……\_软件测试刷题小程序编辑https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502][2024_APP_-CSDN_3.4k_86_15_web_app_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502]

一个测试用例，而不是一个测试断言。

断言轮盘并不意味着多重断言就是坏事。当我指导团队或单个开发人员进行测试驱动开发（TDD）或单元测试时，经常会遇到一种特别的观念： 多个断言是不好的。一个测试必须只有一个断言。这种想法很少有用。让我们看一个实际的代码示例，然后来试着理解这种观念的起源。

##### 由外至内的 TDD #####

考虑使用 REST API 进行和取消餐厅预订。首先，通过 HTTP POST 请求进行预订：

POST /restaurants/1/reservations?sig=epi301tdlc57d0HwLCz[...] HTTP/1.1
    
    Content-Type: application/json
    
    {
    
    "at":"2023-09-22 18:47",
    
    "name":"Teri Bell",
    
    "email":"terrible@example.org",
    
    "quantity":1
    
    }
    
    
    HTTP/1.1201Created
    
    Content-Type: application/json; charset=utf-8
    
    Location:/restaurants/1/reservations/971167d4c79441b78fe70cc702[...]
    
    {
    
    "id":"971167d4c79441b78fe70cc702d3e1f6",
    
    "at":"2023-09-22T18:47:00.0000000",
    
    "email":"terrible@example.org",
    
    "name":"Teri Bell",
    
    "quantity":1
    
    }

请注意，在适当的 REST 方式下，响应会在 Location 标头中返回已创建预订的位置。

如果你改变主意了，可以通过 DELETE 请求取消预订：

DELETE /restaurants/1/reservations/971167d4c79441b78fe70cc702[...] HTTP/1.1
    
    
    HTTP/1.1200 OK

假设这就是我们想要的交互。使用由外至内的TDD编写如下测试:

[Theory]
    
    [InlineData(884,18,47,"c@example.net","Nick Klimenko",2)]
    
    [InlineData(902,18,50,"emot@example.gov","Emma Otting",5)]
    
    public async TaskDeleteReservation(
    
    int days,int hours,int minutes,
    
    string email,string name,int quantity)
    
    {
    
    usingvar api =newLegacyApi();
    
    var at =DateTime.Today.AddDays(days).At(hours, minutes)
    
    .ToIso8601DateTimeString();
    
    var dto =Create.ReservationDto(at, email, name, quantity);
    
    var postResp = await api.PostReservation(dto);
    
    Uri address =FindReservationAddress(postResp);
    
    
    var deleteResp = await api.CreateClient().DeleteAsync(address);
    
    
    Assert.True(
    
            deleteResp.IsSuccessStatusCode,
    
            $"Actual status code: {deleteResp.StatusCode}.");
    
    }

这个例子是在c#中使用xUnit.net，因为我们需要一些语言和框架来展示真实的代码。不过，本文的观点适用于各种语言和框架。本文中的代码示例基于我的著作《Code That Fits in Your Head》中的示例代码库。

为了通过这个测试，你可以像这样实现服务器端代码：

[HttpDelete("restaurants/{restaurantId}/reservations/{id}")]
    
    publicvoidDelete(int restaurantId,string id)
    
    {
    
    }

虽然这显然是一个空操作，但它通过了所有测试。新编写的测试断言 HTTP 响应会返回 200（成功）范围内的状态代码。这是 API 的 REST 协议的一部分，因此该响应非常重要。你希望保留此断言作为回归测试。如果 API 开始返回 400 或 500 范围内的状态代码，这将是一个重大变化。

到目前为止，一切顺利。TDD 是一个渐进的过程。一个测试并不能驱动一个完整的功能。既然所有测试都通过了，你就可以将更改提交到源代码控制中，然后进行下一次迭代。

##### 加强后置条件 #####

你应该能够通过发起一个GET请求来检查资源是否真的消失了:

GET /restaurants/1/reservations/971167d4c79441b78fe70cc702[...] HTTP/1.1
    
    HTTP/1.1404NotFound

然而，这并不是 Delete 当前实现的行为，它什么也没做。这样看来你需要再做一次测试。有一种方法是复制现有测试并更改断言阶段，执行上述 GET 请求，以检查响应状态是否为 404：

[Theory]
    
    [InlineData(884,18,47,"c@example.net","Nick Klimenko",2)]
    
    [InlineData(902,18,50,"emot@example.gov","Emma Otting",5)]
    
    public async TaskDeleteReservationActuallyDeletes(
    
    int days,int hours,int minutes,
    
    string email,string name,int quantity)
    
    {
    
    usingvar api =newLegacyApi();
    
    var at =DateTime.Today.AddDays(days).At(hours, minutes)
    
    .ToIso8601DateTimeString();
    
    var dto =Create.ReservationDto(at, email, name, quantity);
    
    var postResp = await api.PostReservation(dto);
    
    Uri address =FindReservationAddress(postResp);
    
    
    var deleteResp = await api.CreateClient().DeleteAsync(address);
    
    
    var getResp = await api.CreateClient().GetAsync(address);
    
    Assert.Equal(HttpStatusCode.NotFound, getResp.StatusCode);
    
    }

这个方法确实可以提示你正确地实现服务器端Delete方法。但这真的是一个好主意吗？使用这个方法，测试代码是否易于维护呢？

测试代码也是代码，你必须维护它。在测试代码中复制和粘贴会造成问题，原因与在生产代码中复制和粘贴会造成问题的原因相同。如果以后要修改某些内容，你必须确定所有需要编辑的地方。生产代码很容易遗漏掉某一处，从而导致错误。测试代码亦是如此。

##### 一个操作，更多断言 #####

与其复制粘贴第一个测试，为什么不加强第一个测试用例的后置条件呢？

只需在第一个断言后添加新的断言即可：

这意味着你只需要维护一个测试方法，而不是两个几乎完全相同的重复方法。但是，我指导过的一些人可能会说，这个测试有两个断言！的确如此。那又怎样？这是一个测试用例： 取消预订。

虽然取消预订是一个单独的操作，但我们关心的是多个结果：DELETE 请求成功后的状态代码应在 200 范围内。预订资源应该消失了。在进一步开发系统的过程中，我们可能会添加更多我们关心的行为。也许系统还应该发送一封关于取消预订的电子邮件。我们也应该断言这一点。不过，这仍然是相同的测试用例: 成功取消预订。

在一个测试中使用多个断言并没有什么问题。上面的例子说明了它的好处。一个测试用例可以有多个应该被验证的结果。

##### 单一断言概念的起源 #####

每次测试只有一个断言的概念从何而来？我不知道，但我可以猜测。

优秀的《xUnit Test Patterns》一书中描述了一种名为 “断言轮盘”（Assertion Roulette）的测试气味。它描述了一种很难确定到底是哪个断言导致了测试失败的情况。在我看来，每项测试只有一个断言的 “规则 “是对断言轮盘描述的误读造成的。(甚至我自己可能也有责任。我不记得我是否参与过）。

xUnit 测试模式描述了断言轮盘的两个原因：

*  急于测试： 单个测试验证的功能过多。
 *  缺失断言信息。

你可能正试图模拟一个 “会话”，在这个会话中，客户端会执行许多步骤来实现一个目标。正如 Gerard Meszaros 就测试气味所写的那样，这适用于人工测试，但很少用于自动化测试。导致问题的不是断言的数量，而是测试做得太多。

另一个原因是，当断言非常相似时，你无法判断哪一个失败了，同时它们也没有断言信息。

上面例子的情况并非如此。如果 Assert.True 断言失败，断言信息会告诉你：

Actual status code:NotFound.
    
    Expected:True
    
    Actual:False

同样，如果 Assert.Equal 断言失败，也会一目了然：

Assert.Equal()Failure
    
    Expected:NotFound
    
    Actual: OK

这里没有歧义。

##### 一次测试，一个断言 #####

既然你已经明白了每个测试可以有多个断言，那么你就可以无所顾忌地添加断言了。不过，在通常情况下，像 “一次测试，一个断言 “，这样根深蒂固的理念中也蕴含着真理的萌芽。所以需要我们进行正确的判断。

如果你认真思索一下什么是自动化测试，它基本上就是一个谓词。它是一种声明，表明我们期待一种特定的结果。然后，我们将实际结果与预期结果进行比较，看两者是否相等。因此，从本质上讲，理想的断言是这样的：

`Assert.Equal(expected, actual);`

我并不总能实现这一理想断言，但只要能做到，我就会感到非常满足。有时，expected 和 actual 是原始值，如整数或字符串，但它们也可能是复杂值，代表测试所关注的程序状态子集。只要对象在结构上相等，这样的断言就是有意义的。有时，我无法找到像这样简洁表达验证步骤的方法，不得不再添加一两个断言时，我就会这么做。

### 总结 ###

有一种观点认为，每个单元测试只能写一个断言。这可能是出于对错误测试代码的真正担忧，但多年来，”断言轮盘”（Assertion Roulette）这一微妙的测试气味已经变成了一种更简单、但不太有用的 “规则”。

这个“规则”经常会阻碍测试代码的可维护性。遵循“规则”的程序员诉诸于无端的复制和粘贴，而不是在现有测试中添加另一个断言。如果在现有测试中添加相关断言是最好的方法，就不要让一个被误解的规则阻止你。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，**请及时加入群： 759968159**，里面有各种测试开发资料和技术可以一起交流哦。

**最后：** 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取**`【保证100%免费】`**

![06b7bc1a690d4c4f826248342215214c.png][]

**软件测试面试文档**

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

![在这里插入图片描述][cc56d6ee4baf482688db0e1410e2bb51.png]

![在这里插入图片描述][755123cb1321421b96888db976754489.png]

![3010ebc19b1042d4a4e99e0c9334bb1c.gif][]

[5ed80d7da6904639a76a02864c8beec2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/64ae4a8f900c4f3ca5123ef39dea1225.png
[icon-default.png_t_N7T8]: https://csdnimg.cn/release/blog_editor_html/release2.3.6/ckeditor/plugins/CsdnLink/icons/icon-default.png?t=N7T8
[2024_APP_-CSDN_3.4k_86_15_web_app_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_AI_Green_article_details_134931243_spm_1001.2014.3001.5502]: https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502
[06b7bc1a690d4c4f826248342215214c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/0386556df13f49b1a5841fdf3cdc9438.png
[cc56d6ee4baf482688db0e1410e2bb51.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/db553651b947482ab5bc34291a3a5465.png
[755123cb1321421b96888db976754489.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/968ab10e571f41b3b6c7d6340bbe0c6f.png
[3010ebc19b1042d4a4e99e0c9334bb1c.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/c1a02a8ca48a47f787007fafac7f715b.gif