如何避免单元测试陷阱？

逃离我推掉我的手 2023-10-08 14:09 68阅读 0赞

![在这里插入图片描述][5fb87c883155482198a70b4dca710d26.gif_pic_center]  
单元测试的目的是为了随着时间的变化，系统能够按预期工作。一来系统质量得到了保证，开发人员能够提前发现和解决问题，不用身陷bug的泥潭无法自拔；二来开发人员有更多的时间和精力去完善自己技术、提升自己的生活质量，从而形成一个良性循环。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16]  
我写了很多测试，也读了很多。他们中的大多数帮助我及早发现错误，提供代码文档并帮助回归测试。但我也发现一些单元测试没有做到这一点。相反，它们要么非常复杂，以至于无法弄清楚它们在测试什么，要么会随机失败，要么根本不会失败。

本文介绍了导致单元测试无效的五个陷阱，以及如何修复它们。

### 为每个函数编写一个单元测试 ###

看起来很简单。假设您有一个小函数可以做一件事。假设它被称为calculate\_average。它是一个小单元，它是单元测试最佳实践希望您测试的单元。所以你为它写了一个测试，test\_calculate\_average.

这有什么问题？它测试单个代码单元，但它应该测试该单元的单个行为。通常这也被表述为在测试中只有一个断言。一个更好的测试将是test\_calculate\_average\_return\_0\_for\_empty\_list. 一旦您拥有了其中的几个，他们就会免费为您提供详细的文档。

它还改变了您对如何编写测试的思维方式。您必须考虑您期望从函数中获得的不同行为。在不知不觉中，场景越来越多，因为您正在考虑边缘情况，甚至为它们编写测试，所以编写单元测试的收益也逐渐降低。

> **为每个功能单元编写一个单元测试，而不是代码单元。**

测试的重点应该是外部行为，如果我们过渡关注内部行为，当我们对实现逻辑进行了修改，那么原本的单元测试也就无法使用了，也起不到对代码重构保驾护航的作用了，违背了我们写单元测试的初衷，当然如果有一块内部逻辑，非常复杂，你也可以自己进行全覆盖测试，但一般情况下没有必要为了测试而测试。

### 只为代码覆盖率而编写测试 ###

跟踪测试覆盖率通常是一个好主意。如今，许多测试框架都支持这一点，并且像codecov这样的平台可以很容易地随着时间的推移对其进行跟踪。那么，为什么沉迷于它不是一个好的想法呢？

代码覆盖率只是一种测量工具。100% 的代码覆盖率并不意味着你已经覆盖了所有的边缘情况，它只是意味着所有的代码路径都被执行了。这是一个覆盖率 100% 的快速反例，但让我们探讨当您传入一个空列表时会发生什么？

def average(elements: List[int]):
      return sum(elements) / len(elements)
    
    def test_average_returns_average_of_list:
      result = average([1,3,5,7])
      assert result == 4

代码覆盖率的根本问题是它只衡量覆盖了多少行程序。但所有程序都是状态机；要获得完整覆盖，您必须覆盖所有状态，但这是不可行的。

追求完整的，或者至少是非常高的覆盖率也会导致大量的测试，但并不是所有的测试都那么有用。对于胶水代码尤其如此。我见过模拟 Web 框架 (flask) 一半的测试，只是为了测试为端点注册函数是否有效。这是测试一小部分功能的大量工作。如果你弄错了，那就很明显了。一旦你做对了，它在未来不太可能改变。

我没有努力覆盖每一行代码，而是推荐 Martin Fowler 的建议。将测试重点放在有风险的代码上。那是您自己编写的代码，而不是可能会被重构的框架。然而，知道什么是有风险的很困难，因为它需要经验。

> **您应该将 \[您的测试工作\] 集中在风险点上。— Martin Fowler，重构**

特别是某个代码逻辑导致的线上bug，或者其它同学发现的问题，都可以编写成测试用例，防止此类错误的再次出现。

### 严重依赖Mock ###

使用打桩模拟和存根对于单元测试是必不可少的。大多数情况下，您的被测代码与其他模块交互，并且在测试期间，您希望控制它们的行为。这可能导致你过度打桩。

当您必须编写 50 或 100 行模拟来测试单个函数时，那么您在测试什么？您是在测试您的函数，还是在测试您为测试该函数而编写的模拟？

许多Mock模拟也是危险信号。当您需要多个非常复杂的模拟来测试单个函数时，这个函数很可能复杂度过高。因此，您可能希望将其重构为几个功能较少且可以单独测试的函数。

我见过一些非常复杂的模拟。这是一个例子的再现：

# custom_middleware.py ####################################
    class CustomHeaderMiddleware(BaseHTTPMiddleware):
        async def dispatch(self, request, call_next):    
            response = await call_next(request)
            response.headers["CustomField"] = "bla"
            return response
    
    # test_custom_middleware.py ###############################
    async def endpoint_for_test(_):
        return PlainTextResponse("Test")
    
    middleware = [Middleware(CustomHeaderMiddleware)]
    routes = [Route("/test", endpoint=endpoint_for_test)]
    app = Starlette(routes=routes, middleware=middleware)
    
    @pytest.mark.asyncio
    async def test_middleware_sets_field():
        client = TestClient(app)
        response = client.get("/test")
        assert response.headers["CustomField"] == "bla"

这个时候，你不要想办法进行Mock模拟，而是考虑如何进行重构？让其变得更简单，更容易测试。

我们通常通过单元测试去保证代码质量，那么单元测试代码本身的质量又如何保证呢？所以我们的单元测试要写的尽可能简单。

对于对数据一致性要求不高的系统，甚至可以直接对着接口进行测试，这样省去了编写Mock的复杂度。

### 编写永不失败的单元测试 ###

正常情况下，回归是进行单元测试的原因之一。您编写代码，编写通过的测试并获得收益。万一有人破坏了您代码的功能，单元测试将能够发现问题。然而，另外一种情况，您的测试可能永远不会失败并且您会错过回归。

但是，您如何以永不失败的测试结束呢？下面是一个例子：

def get_film(id: str):
        data = {"query": QUERY, "variables": json.dumps({"id": id})}
        response = requests.post(URL, data=data)
        return response.json()["data"]["film"]
    
    def test_get_film_returns_successfully():
        mock_response = {
            "data": {
                "film": {
                "title": "a New Test",
                "id": "testId",
                "episodeID": 4
                }
            }
        }
        with requests_mock.Mocker() as mock:
            mock.post(URL, json=mock_response)
            result = get_film("foo")
            assert result == {
                "title": "a New Test",
                "id": "testId",
                "episodeID": 4
            }

现在问问自己：哪些更改会导致此测试失败？最明显的一个是改变Mock模拟响应。但这不算数，您没有更改被测代码。更糟糕的是，我忘记了传递json.dumps参数. 这个错误不会被测试发现。另外有的同学为了保证测试覆盖率，甚至不写断言，直接打印输出，这样的话，可能永远不会出错。

这种问题被称为误报，看似无懈可击的测试用例，其实没什么用处，为了防止这种情况，请考虑是什么导致您的测试失败。更好的是，从失败的测试开始，然后编写代码直到它通过。在不知不觉中，您正在进行测试驱动开发。

### 使用单元测试保证非确定性行为的正确性 ###

这是一个众所周知的谬论。如果您的测试或被测代码以不确定的方式运行，您将对测试失去信心。每次失败时，你都会问：我的测试失败了，还是会通过重新运行？重新修改运行都会给你的测试用例带来修改的麻烦，你甚至想要放弃单元测试用例。

对于测试来说，不确定性的缺点是显而易见的，那么是什么导致了这种情况呢？

您是否在测试中使用当前时间或日期？如果是，则您的测试每天都在使用不同的数据运行。一旦您从事该行业的时间足够长，您就会遇到这些类型的测试。它们可能仅在该月的最后一天失败，或者仅在午夜之前开始并在之后完成。幸运的是，有一个简单的解决方案：控制时间的流动。例如，Python 具有用于此的freeze-gun模块。

您是否使用随机性来生成示例数据？有一个名为faker的 Python 库，它可以轻松生成真实的数据，如姓名、地址或电话号码。它非常适合填充演示环境或冒烟测试。对于单元测试不是那么有用，通常而言，使用硬编码的单元测试用例最可靠。

如果系统中存在不确定性，那么应该保证固定的逻辑不会出错，对于不确定性的边缘情况应该通过其它方式保证，比如开发、测试人员、寻找更稳定的类库等。

### 总结 ###

这就是阻止您编写有效单元测试的五个陷阱。既然您了解它们，您可以通过执行以下操作来避免它们：

*  为功能的每个部分而不是每个函数编写测试
 *  不痴迷于代码覆盖率，而是专注于测试有风险的代码
 *  最小化Mock模拟代码
 *  确保您的测试可能会失败
 *  将不确定性排除在测试之外

这将使您的系统更加稳定，另外经过良好测试的软件让您可以自信地进行更改和快速部署。

![在这里插入图片描述][a136c83898ea44b1a47a2c2004f3b63d.png_pic_center]

**最后：** 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

**如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！喜欢软件测试的小伙伴们，可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）**

--------------------

### 好文推荐 ###

[转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！][Link 1]

[面试经：一线城市搬砖！又面软件测试岗，5000就知足了…][5000]

[面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…][Link 2]

[什么样的人适合从事软件测试工作？][Link 3]

[那个准点下班的人，比我先升职了…][Link 4]

[测试岗反复跳槽，跳着跳着就跳没了…][Link 5]

[5fb87c883155482198a70b4dca710d26.gif_pic_center]: https://img-blog.csdnimg.cn/5fb87c883155482198a70b4dca710d26.gif#pic_center
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/7cc4834061004fbcaf2cadd52e906fa3.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb,size_20,color_FFFFFF,t_70,g_se,x_16
[a136c83898ea44b1a47a2c2004f3b63d.png_pic_center]: https://img-blog.csdnimg.cn/a136c83898ea44b1a47a2c2004f3b63d.png#pic_center
[Link 1]: https://blog.csdn.net/m0_56736369/article/details/117909132
[5000]: https://blog.csdn.net/m0_56736369/article/details/117915399
[Link 2]: https://blog.csdn.net/weixin_50829653/article/details/117422433
[Link 3]: https://blog.csdn.net/weixin_50271247/article/details/108421434
[Link 4]: https://blog.csdn.net/weixin_50829653/article/details/117856900
[Link 5]: https://blog.csdn.net/m0_56736369/article/details/117923266