通过突变测试来修复未知的 bug。

你一定对所有内容都进行了测试，也许你甚至在项目仓库中有一个徽章，标明有 100% 的测试覆盖率，但是这些测试真的帮到你了吗？你怎么知道的？

开发人员很清楚单元测试的成本。测试必须要编写。有时它们无法按照预期工作：存在假告警或者抖动测试。在不更改任何代码的情况下有时成功，有时失败。通过单元测试发现的小问题很有价值，但是通常它们悄无声息的出现在开发人员的机器上，并且在提交到版本控制之前就已得到修复。但真正令人担忧的问题大多是看不见的。最糟糕的是，丢失的告警是完全不可见的：你看不到没能捕获的错误，直到出现在用户手上 —— 有时甚至连用户都看不到。

有一种测试可以使不可见的错误变为可见： 突变测试 mutation testing 。

变异测试通过算法修改源代码，并检查每次测试是否都有“变异体”存活。任何在单元测试中幸存下来的变异体都是问题：这意味着对代码的修改（可能会引入错误）没有被标准测试套件捕获。

Python 中用于突变测试的一个框架是 mutmut。

假设你需要编写代码来计算钟表中时针和分针之间的角度，直到最接近的度数，代码可能会这样写：

def hours_hand(hour, minutes):
    base = (hour % 12 ) * (360 // 12)
    correction = int((minutes / 60) * (360 // 12))
    return base + correction

def minutes_hand(hour, minutes):
    return minutes * (360 // 60)

def between(hour, minutes):
    return abs(hours_hand(hour, minutes) - minutes_hand(hour, minutes))

首先，写一个简单的单元测试：

import angle

def test_twelve():
    assert angle.between(12, 00) == 0

足够了吗？代码没有 if 语句，所以如果你查看覆盖率：

$ coverage run `which pytest`
============================= test session starts ==============================
platform linux -- Python 3.8.3, pytest-5.4.3, py-1.8.2, pluggy-0.13.1
rootdir: /home/moshez/src/mut-mut-test
collected 1 item                                                              

tests/test_angle.py .                                                    [100%]

============================== 1 passed in 0.01s ===============================

完美！测试通过，覆盖率为 100%，你真的是一个测试专家。但是，当你使用突变测试时，覆盖率会变成多少？

$ mutmut run --paths-to-mutate angle.py
<snip>
Legend for output:
? Killed mutants.   The goal is for everything to end up in this bucket.
⏰ Timeout.          Test suite took 10 times as long as the baseline so were killed.
? Suspicious.       Tests took a long time, but not long enough to be fatal.
? Survived.         This means your tests needs to be expanded.
? Skipped.          Skipped.
<snip>
⠋ 21/21  ? 5  ⏰ 0  ? 0  ? 16  ? 0

天啊，在 21 个突变体中，有 16 个存活。只有 5 个通过了突变测试，但是，这意味着什么呢？

对于每个突变测试，mutmut 会修改部分源代码，以模拟潜在的错误，修改的一个例子是将 > 比较更改为 >=，查看会发生什么。如果没有针对这个边界条件的单元测试，那么这个突变将会“存活”：这是一个没有任何测试用例能够检测到的潜在错误。

是时候编写更好的单元测试了。很容易检查使用 results 所做的更改：

$ mutmut results
<snip>
Survived ? (16)

---- angle.py (16) ----

4-7, 9-14, 16-21
$ mutmut apply 4
$ git diff
diff --git a/angle.py b/angle.py
index b5dca41..3939353 100644
--- a/angle.py
+++ b/angle.py
@@ -1,6 +1,6 @@
 def hours_hand(hour, minutes):
     hour = hour % 12
-    base = hour * (360 // 12)
+    base = hour / (360 // 12)
     correction = int((minutes / 60) * (360 // 12))
     return base + correction

这是 mutmut 执行突变的一个典型例子，它会分析源代码并将运算符更改为不同的运算符：减法变加法。在本例中由乘法变为除法。一般来说，单元测试应该在操作符更换时捕获错误。否则，它们将无法有效地测试行为。按照这种逻辑，mutmut 会遍历源代码仔细检查你的测试。

你可以使用 mutmut apply 来应用失败的突变体。事实证明你几乎没有检查过 hour 参数是否被正确使用。修复它：

$ git diff
diff --git a/tests/test_angle.py b/tests/test_angle.py
index f51d43a..1a2e4df 100644
--- a/tests/test_angle.py
+++ b/tests/test_angle.py
@@ -2,3 +2,6 @@ import angle
 
 def test_twelve():
     assert angle.between(12, 00) == 0
+
+def test_three():
+    assert angle.between(3, 00) == 90

以前，你只测试了 12 点钟，现在增加一个 3 点钟的测试就足够了吗？

$ mutmut run --paths-to-mutate angle.py
<snip>
⠋ 21/21  ? 7  ⏰ 0  ? 0  ? 14  ? 0

这项新测试成功杀死了两个突变体，比以前更好，当然还有很长的路要走。我不会一一解决剩下的 14 个测试用例，因为我认为模式已经很明确了。（你能将它们降低到零吗？）

变异测试和覆盖率一样，是一种工具，它允许你查看测试套件的全面程度。使用它使得测试用例需要改进：那些幸存的突变体中的任何一个都是人类在篡改代码时可能犯的错误，以及潜伏在程序中的隐藏错误。继续测试，愉快地搜寻 bug 吧。

via: https://opensource.com/article/20/7/mutmut-python

作者：Moshe Zadka 选题：lujun9972 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

持续集成和持续交付是由测试驱动的。以下是如何做到的。

“如果一切似乎都在控制之中，那只是你走的不够快而已。” —Mario Andretti

测试自动化是指在软件开发过程中尽可能早、尽可能快地持续关注检测缺陷、错误和 bug。这是通过使用那些追求质量为最高价值的工具完成的，它们旨在确保质量，而不仅仅是追求质量。

持续集成/持续交付（CI/CD）解决方案（也称为 DevOps 管道）最引人注目的功能之一是可以更频繁地进行测试，而又不会给开发人员或操作人员增加更多的手动工作。让我们谈谈为什么这很重要。

为什么要在 CI/CD 中实现自动化测试？

敏捷团队要更快的迭代，以更高的速度交付软件和客户满意度，而这些压力可能会危及质量。全球竞争制造了对缺陷的低容忍度，同时也增加了敏捷团队的压力，要求软件交付的迭代更快。减轻这种压力的行业解决方案是什么？是 DevOps。

DevOps 是一个大概念，有很多定义，但是对 DevOps 成功至关重要的一项技术是 CI/CD。通过软件开发流程设计一个连续的改进循环，可以为测试带来新的机会。

这对测试人员意味着什么？

对于测试人员，这通常意味着他们必须：

• 更早且更频繁地进行测试（使用自动化）
• 持续测试“真实世界”的工作流（自动和手动）

更具体地说，任何形式的测试，无论是由编写代码的开发人员运行还是由质量保证工程师团队设计，其作用都是利用 CI/CD 基础架构在快速推进的同时提高质量。

测试人员还需要做什么？

具体点说，测试人员负责：

• 测试新的和现有的软件应用
• 根据系统要求评估软件来验证和确认功能
• 利用自动化测试工具来开发和维护可重复使用的自动化测试
• 与 scrum 团队的所有成员合作，了解正在开发的功能以及实施的技术设计，以设计和开发准确、高质量的自动化测试
• 分析记录在案的用户需求，并针对中等到高度复杂的软件或 IT 系统制定或协助设计测试计划
• 开发自动化测试，并与功能团队一起审查和评估测试方案
• 与技术团队合作，确定在开发环境中自动化测试的正确方法
• 与团队合作，通过自动化测试来了解和解决软件问题，并回应有关修改或增强的建议
• 参与需求梳理、估算和其他敏捷 scrum 仪式
• 协助制定标准和流程，以支持测试活动和材料（例如脚本、配置、程序、工具、计划和结果）

测试是一项艰巨的工作，但这是有效构建软件的重要组成部分。

哪些持续测试很重要？

你可以使用多种测试。不同的类型并不是学科之间的牢固界限。相反，它们是表示如何测试的不同方式。比较测试类型不太重要，更重要的是对每一种测试类型都要有覆盖率。

• 功能测试： 确保软件具有其要求的功能
• 单元测试： 独立测试软件的较小单元/组件以检查其功能
• 负载测试： 测试软件在重负载或使用期间的性能
• 压力测试： 确定软件承受压力（最大负载）时的断点
• 集成测试： 测试组合或集成的一组组件的输出
• 回归测试： 当修改任意组件（无论多么小），测试整个应用的功能

总结

任何包含持续测试的软件开发过程都将朝着建立关键反馈环路的方向发展，以实现快速和构建有效的软件。最重要的是，该实践将质量内置到 CI/CD 管道中，并意味着了解在软件开发生命周期中提高速度同时减少风险和浪费之间的联系。

via: https://opensource.com/article/20/7/automation-testing-cicd

作者：Taz Brown 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

使用此框架编写断言，提高开发测试的准确性。

在测试金字塔的底部是单元测试。单元测试每次只测试一个代码单元，通常是一个函数或方法。

通常，设计单个单元测试是为了测试通过一个函数或特定分支的特定执行流程，这使得将失败的单元测试和导致失败的 bug 对应起来变得容易。

理想情况下，单元测试很少使用或不使用外部资源，从而隔离它们并使它们更快。

单元测试套件通过在开发过程的早期发现问题来帮助维护高质量的产品。有效的单元测试可以在代码离开开发人员机器之前捕获 bug，或者至少可以在特定分支上的持续集成环境中捕获 bug。这标志着好的和坏的单元测试之间的区别：好的测试通过尽早捕获 bug 并使测试更快来提高开发人员的生产力。坏的测试降低了开发人员的工作效率。

当测试附带的特性时，生产率通常会降低。当代码更改时测试会失败，即使它仍然是正确的。发生这种情况是因为输出的不同，但在某种程度上是因为它不是 函数契约 function’s contract 的一部分。

因此，一个好的单元测试可以帮助执行函数所提交的契约。

如果单元测试中断，那意味着该契约被违反了，应该（通过更改文档和测试）明确修改，或者（通过修复代码并保持测试不变）来修复。

虽然将测试限制为只执行公共契约是一项需要学习的复杂技能，但有一些工具可以提供帮助。

其中一个工具是 Hamcrest，这是一个用于编写断言的框架。最初是为基于 Java 的单元测试而发明的，但它现在支持多种语言，包括 Python。

Hamcrest 旨在使测试断言更容易编写和更精确。

def add(a, b):
    return a + b

from hamcrest import assert_that, equal_to

def test_add():
    assert_that(add(2, 2), equal_to(4))  

这是一个用于简单函数的断言。如果我们想要断言更复杂的函数怎么办？

def test_set_removal():
    my_set = {1, 2, 3, 4}
    my_set.remove(3)
    assert_that(my_set, contains_inanyorder([1, 2, 4]))
    assert_that(my_set, is_not(has_item(3)))

注意，我们可以简单地断言其结果是任何顺序的 1、2 和 4，因为集合不保证顺序。

我们也可以很容易用 is_not 来否定断言。这有助于我们编写精确的断言，使我们能够把自己限制在执行函数的公共契约方面。

然而，有时候，内置的功能都不是我们真正需要的。在这些情况下，Hamcrest 允许我们编写自己的 匹配器 matchers 。

想象一下以下功能：

def scale_one(a, b):
    scale = random.randint(0, 5)
    pick = random.choice([a,b])
    return scale * pick

我们可以自信地断言其结果均匀地分配到至少一个输入。

匹配器继承自 hamcrest.core.base_matcher.BaseMatcher，重写两个方法：

class DivisibleBy(hamcrest.core.base_matcher.BaseMatcher):
    def __init__(self, factor):
        self.factor = factor

    def _matches(self, item):
        return (item % self.factor) == 0

    def describe_to(self, description):
        description.append_text('number divisible by')
        description.append_text(repr(self.factor))

编写高质量的 describe_to 方法很重要，因为这是测试失败时显示的消息的一部分。

def divisible_by(num):
    return DivisibleBy(num)

按照惯例，我们将匹配器包装在一个函数中。有时这给了我们进一步处理输入的机会，但在这种情况下，我们不需要进一步处理。

def test_scale():
    result = scale_one(3, 7)
    assert_that(result,
                any_of(divisible_by(3),
                divisible_by(7)))

请注意，我们将 divisible_by 匹配器与内置的 any_of 匹配器结合起来，以确保我们只测试函数提交的内容。

在编辑这篇文章时，我听到一个传言，取 “Hamcrest” 这个名字是因为它是 “matches” 字母组成的字谜。嗯…

>>> assert_that("matches", contains_inanyorder(*"hamcrest")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/moshez/src/devops-python/build/devops/lib/python3.6/site-packages/hamcrest/core/assert_that.py", line 43, in assert_that
    _assert_match(actual=arg1, matcher=arg2, reason=arg3)
  File "/home/moshez/src/devops-python/build/devops/lib/python3.6/site-packages/hamcrest/core/assert_that.py", line 57, in _assert_match
    raise AssertionError(description)
AssertionError:
Expected: a sequence over ['h', 'a', 'm', 'c', 'r', 'e', 's', 't'] in any order
      but: no item matches: 'r' in ['m', 'a', 't', 'c', 'h', 'e', 's']

经过进一步的研究，我找到了传言的来源：它是 “matchers” 字母组成的字谜。

>>> assert_that("matchers", contains_inanyorder(*"hamcrest"))
>>>

如果你还没有为你的 Python 代码编写单元测试，那么现在是开始的好时机。如果你正在为你的 Python 代码编写单元测试，那么使用 Hamcrest 将允许你使你的断言更加精确，既不会比你想要测试的多也不会少。这将在修改代码时减少误报，并减少修改工作代码的测试所花费的时间。

via: https://opensource.com/article/18/8/robust-unit-tests-hamcrest

作者：Moshe Zadka 选题：lujun9972 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Selenium 是浏览器自动化的绝佳工具。使用 Selenium IDE，你可以录制命令序列（如单击、拖动和输入），验证结果并最终存储此自动化测试供日后使用。这非常适合在浏览器中进行活跃开发。但是当你想要将这些测试与 CI/CD 流集成时，是时候使用 Selenium WebDriver 了。

WebDriver 公开了一个绑定了许多编程语言的 API，它允许你将浏览器测试与其他测试集成。这篇文章向你展示了如何在容器中运行 WebDriver 并将其与 Python 程序一起使用。

使用 Podman 运行 Selenium

Podman 是下面例子的容器运行时。有关如何开始使用 Podman 的信息，请参见此前文章。

此例使用了 Selenium 的独立容器，其中包含 WebDriver 服务器和浏览器本身。要在后台启动服务器容器，请运行以下命令：

$ podman run -d --network host --privileged --name server docker.io/selenium/standalone-firefox

当你使用特权标志和主机网络运行容器时，你可以稍后从在 Python 中连接到此容器。你不需要使用 sudo。

在 Python 中使用 Selenium

现在你可以提供一个使用此服务器的简单程序。这个程序很小，但应该会让你知道可以做什么：

from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

server ="http://127.0.0.1:4444/wd/hub"

driver = webdriver.Remote(command_executor=server,
    desired_capabilities=DesiredCapabilities.FIREFOX)

print("Loading page...")
driver.get("https://fedoramagazine.org/")
print("Loaded")
assert "Fedora" in driver.title

driver.quit()
print("Done.")

首先，程序连接到你已经启动的容器。然后它加载 Fedora Magazine 网页并判断 “Fedora” 是页面标题的一部分。最后，它退出会话。

需要 Python 绑定才能运行此程序。既然你已经在使用容器了，为什么不在容器中这样做呢？将以下内容保存到 Dockerfile 中：

FROM fedora:29
RUN dnf -y install python3
RUN pip3 install selenium

然后使用 Podman 在与 Dockerfile 相同的文件夹中构建容器镜像：

$ podman build -t selenium-python .

要在容器中运行程序，在运行容器时将包含 Python 代码的文件作为卷挂载：

$ podman run -t --rm --network host \
 -v $(pwd)/browser-test.py:/browser-test.py:z \
 selenium-python python3 browser-test.py

输出看上去像这样：

Loading page...
Loaded
Done.

接下来做什么

上面的示例程序是最小的，也许没那么有用。但这仅仅是最表面的东西！查看 Selenium 和 Python 绑定 的文档。在那里，你将找到有关如何在页面中查找元素、处理弹出窗口或填写表单的示例。拖放也是可能的，当然还有等待事件。

在实现一些不错的测试后，你可能希望将它们包含在 CI/CD 流程中。幸运的是，这是相当直接的，因为一切都是容器化的。

你可能也有兴趣设置 grid 来并行运行测试。这不仅有助于加快速度，还允许你同时测试多个不同的浏览器。

清理

当你容器使用完后，可以使用以下命令停止并删除独立容器：

$ podman stop server
$ podman rm server

如果你还想释放磁盘空间，请运行以下命令删除镜像：

$ podman rmi docker.io/selenium/standalone-firefox
$ podman rmi selenium-python fedora:29

总结

在本篇中，你已经看到使用容器技术开始使用 Selenium 是多么容易。它允许你自动化与网站的交互，以及测试交互。Podman 允许你在没有超级用户权限或 Docker 守护程序的情况下运行所需的容器。最后，Python 绑定允许你使用普通的 Python 代码与浏览器进行交互。

via: https://fedoramagazine.org/automate-web-browser-selenium/

作者：Lennart Jern 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

越来越多的开发人员使用容器开发和部署他们的应用。这意味着可以轻松地测试容器也变得很重要。Conu (container utilities 的简写) 是一个 Python 库，让你编写容器测试变得简单。本文向你介绍如何使用它测试容器。

开始吧

首先，你需要一个容器程序来测试。为此，以下命令创建一个包含一个容器的 Dockerfile 和一个被容器伺服的 Flask 应用程序的文件夹。

$ mkdir container_test
$ cd container_test
$ touch Dockerfile
$ touch app.py

将以下代码复制到 app.py 文件中。这是惯常的基本 Flask 应用，它返回字符串 “Hello Container World！”。

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello Container World!'

if __name__ == '__main__':
    app.run(debug=True,host='0.0.0.0')

创建和构建测试容器

为了构建测试容器，将以下指令添加到 Dockerfile。

FROM registry.fedoraproject.org/fedora-minimal:latest
RUN microdnf -y install python3-flask && microdnf clean all
ADD ./app.py /srv
CMD ["python3", "/srv/app.py"]

然后使用 Docker CLI 工具构建容器。

$ sudo dnf -y install docker
$ sudo systemctl start docker
$ sudo docker build . -t flaskapp_container

提示：只有在系统上未安装 Docker 时才需要前两个命令。

构建之后使用以下命令运行容器。

$ sudo docker run -p 5000:5000 --rm flaskapp_container
* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 473-505-51

最后，使用 curl 检查 Flask 应用程序是否在容器内正确运行：

$ curl http://127.0.0.1:5000
Hello Container World!

现在，flaskapp\_container 正在运行并准备好进行测试，你可以使用 Ctrl+C 将其停止。

创建测试脚本

在编写测试脚本之前，必须安装 conu。在先前创建的 container_test 目录中，运行以下命令。

$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv)$ pip install --upgrade pip
(.venv)$ pip install conu
$ touch test_container.py

然后将以下脚本复制并保存在 test_container.py 文件中。

import conu

PORT = 5000

with conu.DockerBackend() as backend:
  image = backend.ImageClass("flaskapp_container")
  options = ["-p", "5000:5000"]
  container = image.run_via_binary(additional_opts=options)
  
  try:
    # Check that the container is running and wait for the flask application to start.
    assert container.is_running()
    container.wait_for_port(PORT)
    
    # Run a GET request on / port 5000.
    http_response = container.http_request(path="/", port=PORT)
    
    # Check the response status code is 200
    assert http_response.ok
    
    # Get the response content
    response_content = http_response.content.decode("utf-8")

    # Check that the "Hello Container World!" string is served.
    assert "Hello Container World!" in response_content

    # Get the logs from the container
    logs = [line for line in container.logs()]
    # Check the the Flask application saw the GET request.
    assert b'"GET / HTTP/1.1" 200 -' in logs[-1]

  finally:
    container.stop()
    container.delete()

测试设置

这个脚本首先设置 conu 使用 Docker 作为后端来运行容器。然后它设置容器镜像以使用你在本教程第一部分中构建的 flaskapp\_container。

下一步是配置运行容器所需的选项。在此示例中，Flask 应用在端口5000上提供内容。于是你需要暴露此端口并将其映射到主机上的同一端口。

最后，用这个脚本启动容器，现在可以测试了。

测试方法

在测试容器之前，检查容器是否正在运行并准备就绪。示范脚本使用 container.is_running 和 container.wait_for_port。这些方法可确保容器正在运行，并且服务在预设端口上可用。

container.http_request 是 request 库的包装器，可以方便地在测试期间发送 HTTP 请求。这个方法返回requests.Responseobject，因此可以轻松地访问响应的内容以进行测试。

conu 还可以访问容器日志。又一次，这在测试期间非常有用。在上面的示例中，container.logs 方法返回容器日志。你可以使用它们断言打印了特定日志，或者，例如在测试期间没有异常被引发。

conu 提供了许多与容器接合的有用方法。文档中提供了完整的 API 列表。你还可以参考 GitHub 上提供的示例。

运行本教程所需的所有代码和文件也可以在 GitHub 上获得。 对于想要进一步采用这个例子的读者，你可以看看使用 pytest 来运行测试并构建一个容器测试套件。

via: https://fedoramagazine.org/test-containers-python-conu/

作者：Clément Verna 选题：lujun9972 译者：GraveAccent 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Python 测试工具最好的一方面是其强大的生态系统。这里列出了八个最好的插件。

我们是 pytest 的忠实粉丝，并将其作为工作和开源项目的默认 Python 测试工具。在本月的 Python 专栏中，我们分享了为什么我们喜欢 pytest 以及一些让 pytest 测试工作更有趣的插件。

什么是 pytest？

正如该工具的网站所说，“pytest 框架可以轻松地编写小型测试，也能进行扩展以支持应用和库的复杂功能测试。”

pytest 允许你在任何名为 test_*.py 的文件中定义测试，并将其定义为以 test_* 开头的函数。然后，pytest 将在整个项目中查找所有测试，并在控制台中运行 pytest 时自动运行这些测试。pytest 接受标志和参数，它们可以在测试运行器停止时更改，这些包含如何输出结果，运行哪些测试以及输出中包含哪些信息。它还包括一个 set_trace() 函数，它可以进入到你的测试中。它会暂停您的测试， 并允许你与变量进行交互，不然你只能在终端中“四处翻弄”来调试你的项目。

pytest 最好的一方面是其强大的插件生态系统。因为 pytest 是一个非常流行的测试库，所以多年来创建了许多插件来扩展、定制和增强其功能。这八个插件是我们的最爱。

8 个很棒的插件

1、pytest-sugar

pytest-sugar 改变了 pytest 的默认外观，添加了一个进度条，并立即显示失败的测试。它不需要配置，只需 pip install pytest-sugar，用 pytest 运行测试，来享受更漂亮、更有用的输出。

2、pytest-cov

pytest-cov 在 pytest 中增加了覆盖率支持，来显示哪些代码行已经测试过，哪些还没有。它还将包括项目的测试覆盖率。

3、pytest-picked

pytest-picked 对你已经修改但尚未提交 git 的代码运行测试。安装库并运行 pytest --picked 来仅测试自上次提交后已更改的文件。

4、pytest-instafail

pytest-instafail 修改 pytest 的默认行为来立即显示失败和错误，而不是等到 pytest 完成所有测试。

5、pytest-tldr

一个全新的 pytest 插件，可以将输出限制为你需要的东西。pytest-tldr（tldr 代表 “too long, didn’t read” —— 太长，不想读），就像 pytest-sugar 一样，除基本安装外不需要配置。不像 pytest 的默认输出那么详细，pytest-tldr 将默认输出限制为失败测试的回溯信息，并忽略了一些令人讨厌的颜色编码。添加 -v 标志会为喜欢它的人返回更详细的输出。

6、pytest-xdist

pytest-xdist 允许你通过 -n 标志并行运行多个测试：例如，pytest -n 2 将在两个 CPU 上运行你的测试。这可以显著加快你的测试速度。它还包括 --looponfail 标志，它将自动重新运行你的失败测试。

7、pytest-django

pytest-django 为 Django 应用和项目添加了 pytest 支持。具体来说，pytest-django 引入了使用 pytest fixture 测试 Django 项目的能力，而省略了导入 unittest 和复制/粘贴其他样板测试代码的需要，并且比标准的 Django 测试套件运行得更快。

8、django-test-plus

django-test-plus 并不是专门为 pytest 开发，但它现在支持 pytest。它包含自己的 TestCase 类，你的测试可以继承该类，并使你能够使用较少的按键来输出频繁的测试案例，例如检查特定的 HTTP 错误代码。

我们上面提到的库绝不是你扩展 pytest 的唯一选择。有用的 pytest 插件的前景是广阔的。查看 pytest 插件兼容性页面来自行探索。你最喜欢哪些插件？

via: https://opensource.com/article/18/6/pytest-plugins

作者：Jeff Triplett, Lacery Williams Henschel 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出