- 当前位置：首页 >域名 >用 Python 测试 API 的三种方式
用 Python 测试 API 的三种方式
发布时间：2025-11-05 13:06:54 来源：创站工坊 作者：IT科技
在这个教程中，你将学到如何对执行 HTTP 请求代码的进行单元测试。也就是说，你将看到用 Python 对 API 进行单元测试的艺术。
单元测试是指对单个行为的测试。在测试中，一个众所周知的经验法则就是隔离那些需要外部依赖的代码。
比如，当测试一段执行 HTTP 请求的代码时，建议在测试过程中，把真正的调用替换成一个假的的调用。这种情况下，每次运行测试的时候，就可以对它进行单元测试，而不需要执行一个真正的 HTTP 请求。
问题就是，怎样才能隔离这些代码？
这就是我希望在这篇博文中回答的问题！亿华云我不仅会向你展示如果去做，而且也会权衡不同方法之间的优点和缺点。
要求：
Python 3.8pytest-mockrequestsflaskresponsesVCR.py使用一个天气状况 REST API 的演示程序
为了更好的解决这个问题，假设你正在创建一个天气状况的应用。这个应用使用第三方天气状况 REST API 来检索一个城市的天气信息。其中一个需求是生成一个简单的 HTML 页面，像下面这个图片：
伦敦的天气，OpenWeatherMap。图片是作者自己制作的。
为了获得天气的信息，必须得去某个地方找。幸运的是，通过 OpenWeatherMap 的 REST API 服务，可以获得一切需要的信息。
好的，很棒，但是WordPress模板我该怎么用呢？
通过发送一个 GET 请求到：https://api.openweathermap.org/data/2.5/weather?q={city_name}&appid={api_key}&units=metric，就可以获得你所需要的所有东西。在这个教程中，我会把城市名字设置成一个参数，并确定使用公制单位。
检索数据
使用 requests 模块来检索天气数据。你可以创建一个接收城市名字作为参数的函数，然后返回一个 JSON。JSON 包含温度、天气状况的描述、日出和日落时间等数据。
下面的例子演示了这样一个函数：
def find_weather_for(city: str) -> dict:
"""Queries the weather API and returns the weather data for a particular city."""
url = API.format(city_name=city, api_key=API_KEY)
resp = requests.get(url)
return resp.json()这个 URL 是由两个全局变量构成：
BASE_URL = "https://api.openweathermap.org/data/2.5/weather"
API = BASE_URL + "?q={city_name}&appid={api_key}&units=metric"API 以这个格式返回了一个 JSON：
{
"coord": {
"lon": -0.13,
"lat": 51.51
},
"weather": [
{
"id": 800,
"main": "Clear",
"description": "clear sky",
"icon": "01d"
}
],
"base": "stations",
"main": {
"temp": 16.53,
"feels_like": 15.52,
"temp_min": 15,
"temp_max": 17.78,
"pressure": 1023,
"humidity": 72
},
"visibility": 10000,
"wind": {
"speed": 2.1,
"deg": 40
},
"clouds": {
"all": 0
},
"dt": 1600420164,
"sys": {
"type": 1,
"id": 1414,
"country": "GB",
"sunrise": 1600407646,
"sunset": 1600452509
},
"timezone": 3600,
"id": 2643743,
"name": "London",
"cod": 200当调用 resp.json() 的时候，数据是以 Python 字典的形式返回的。为了封装所有细节，可以用 dataclass 来表示它们。这个类有一个工厂方法，可以获得这个字典并且返回一个 WeatherInfo 实例。
这种办法很好，因为可以保持这种表示方法的稳定。比如，如果 API 改变了 JSON 的结构，就可以在同一个地方（from_dict 方法中）修改逻辑。云服务器其他代码不会受影响。你也可以从不同的源获得信息，然后把它们都整合到 from_dict 方法中。
@dataclass
class WeatherInfo:
temp: float
sunset: str
sunrise: str
temp_min: float
temp_max: float
desc: str
@classmethod
def from_dict(cls, data: dict) -> "WeatherInfo":
return cls(
temp=data["main"]["temp"],
temp_min=data["main"]["temp_min"],
temp_max=data["main"]["temp_max"],
desc=data["weather"][0]["main"],
sunset=format_date(data["sys"]["sunset"]),
sunrise=format_date(data["sys"]["sunrise"]),
)现在来创建一个叫做 retrieve_weather 的函数。使用这个函数调用 API，然后返回一个 WeatherInfo，这样就可创建你自己的 HTML 页面。
def retrieve_weather(city: str) -> WeatherInfo:
"""Finds the weather for a city and returns a WeatherInfo instance."""
data = find_weather_for(city)
return WeatherInfo.from_dict(data)很好，我们的 app 现在有一些基础了。在继续之前，对这些函数进行单元测试。
1、使用 mock 测试 API
根据维基百科，模拟对象mock object是通过模仿真实对象来模拟它行为的一个对象。在 Python 中，你可以使用 unittest.mock 库来模拟mock任何对象，这个库是标准库中的一部分。为了测试 retrieve_weather 函数，可以模拟 requests.get，然后返回静态数据。
pytest-mock在这个教程中，会使用 pytest 作为测试框架。通过插件，pytest 库是非常具有扩展性的。为了完成我们的模拟目标，要用 pytest-mock。这个插件抽象化了大量 unittest.mock 中的设置，也会让你的代码更简洁。如果你感兴趣的话，我在 另一篇博文中 会有更多的讨论。
好的，言归正传，现在看代码。
下面是一个 retrieve_weather 函数的完整测试用例。这个测试使用了两个 fixture：一个是由 pytest-mock 插件提供的 mocker fixture, 还有一个是我们自己的。就是从之前请求中保存的静态数据。
@pytest.fixture()
def fake_weather_info():
"""Fixture that returns a static weather data."""
with open("tests/resources/weather.json") as f:
return json.load(f) def test_retrieve_weather_using_mocks(mocker, fake_weather_info):
"""Given a city name, test that a HTML report about the weather is generated
correctly."""
# Creates a fake requests response object
fake_resp = mocker.Mock()
# Mock the json method to return the static weather data
fake_resp.json = mocker.Mock(return_value=fake_weather_info)
# Mock the status code
fake_resp.status_code = HTTPStatus.OK
mocker.patch("weather_app.requests.get", return_value=fake_resp)
weather_info = retrieve_weather(city="London")
assert weather_info == WeatherInfo.from_dict(fake_weather_info)如果运行这个测试，会获得下面的输出：
============================= test session starts ==============================
...[omitted]...
tests/test_weather_app.py::test_retrieve_weather_using_mocks PASSED [100%]
============================== 1 passed in 0.20s ===============================
Process finished with exit code 0很好，测试通过了！但是...生活并非一帆风顺。这个测试有优点，也有缺点。现在来看一下。
优点好的，有一个之前讨论过的优点就是，通过模拟 API 的返回值，测试变得简单了。将通信和 API 隔离，这样测试就可以预测了。这样总会返回你需要的东西。
缺点对于缺点，问题就是，如果不再想用 requests 了，并且决定回到标准库的 urllib，怎么办。每次改变 find_weather_for 的代码，都得去适配测试。好的测试是，当你修改代码实现的时候，测试时不需要改变的。所以，通过模拟，你最终把测试和实现耦合在了一起。
而且，另一个不好的方面是你需要在调用函数之前进行大量设置——至少是三行代码。
...
# Creates a fake requests response object
fake_resp = mocker.Mock()
# Mock the json method to return the static weather data
fake_resp.json = mocker.Mock(return_value=fake_weather_info)
# Mock the status code
fake_resp.status_code = HTTPStatus.OK
...我可以做的更好吗？
是的，请继续看。我现在看看怎么改进一点。
使用 responses
用 mocker 功能模拟 requests 有点问题，就是有很多设置。避免这个问题的一个好办法就是使用一个库，可以拦截 requests 调用并且给它们 打补丁patch。有不止一个库可以做这件事，但是对我来说最简单的是 responses。我们来看一下怎么用，并且替换 mock。
@responses.activate
def test_retrieve_weather_using_responses(fake_weather_info):
"""Given a city name, test that a HTML report about the weather is generated
correctly."""
api_uri = API.format(city_name="London", api_key=API_KEY)
responses.add(responses.GET, api_uri, json=fake_weather_info, status=HTTPStatus.OK)
weather_info = retrieve_weather(city="London")
assert weather_info == WeatherInfo.from_dict(fake_weather_info)这个函数再次使用了我们的 fake_weather_info fixture。
然后运行测试：
============================= test session starts ==============================
...
tests/test_weather_app.py::test_retrieve_weather_using_responses PASSED [100%]
============================== 1 passed in 0.19s ===============================非常好！测试也通过了。但是...并不是那么棒。
优点使用诸如 responses 这样的库，好的方面就是不需要再给 requests 打补丁patch。通过将这层抽象交给库，可以减少一些设置。然而，如果你没注意到的话，还是有一些问题。
缺点和 unittest.mock 很像，测试和实现再一次耦合了。如果替换 requests，测试就不能用了。
2、使用适配器测试 API
如果用模拟让测试耦合了，我能做什么？
设想下面的场景：假如说你不能再用 requests 了，而且必须要用 urllib 替换，因为这是 Python 自带的。不仅仅是这样，你了解了不要把测试代码和实现耦合，并且你想今后都避免这种情况。你想替换 urllib，也不想重写测试了。
事实证明，你可以抽象出执行 GET 请求的代码。
真的吗？怎么做？
可以使用适配器adapter来抽象它。适配器是一种用来封装其他类的接口，并作为新接口暴露出来的一种设计模式。用这种方式，就可以修改适配器而不需要修改代码了。比如，在 find_weather_for 函数中，封装关于 requests 的所有细节，然后把这部分暴露给只接受 URL 的函数。
所以，这个：
def find_weather_for(city: str) -> dict:
"""Queries the weather API and returns the weather data for a particular city."""
url = API.format(city_name=city, api_key=API_KEY)
resp = requests.get(url)
return resp.json()变成这样：
def find_weather_for(city: str) -> dict:
"""Queries the weather API and returns the weather data for a particular city."""
url = API.format(city_name=city, api_key=API_KEY)
return adapter(url)然后适配器变成这样：
def requests_adapter(url: str) -> dict:
resp = requests.get(url)
return resp.json()现在到了重构 retrieve_weather 函数的时候：
def retrieve_weather(city: str) -> WeatherInfo:
"""Finds the weather for a city and returns a WeatherInfo instance."""
data = find_weather_for(city, adapter=requests_adapter)
return WeatherInfo.from_dict(data)所以，如果你决定改为使用 urllib 的实现，只要换一下适配器：
def urllib_adapter(url: str) -> dict:
"""An adapter that encapsulates urllib.urlopen"""
with urllib.request.urlopen(url) as response:
resp = response.read()
return json.loads(resp) def retrieve_weather(city: str) -> WeatherInfo:
"""Finds the weather for a city and returns a WeatherInfo instance."""
data = find_weather_for(city, adapter=urllib_adapter)
return WeatherInfo.from_dict(data)好的，那测试怎么做？
为了测试 retrieve_weather, 只要创建一个在测试过程中使用的假的适配器：
@responses.activate
def test_retrieve_weather_using_adapter(
fake_weather_info,
):
def fake_adapter(url: str):
return fake_weather_info
weather_info = retrieve_weather(city="London", adapter=fake_adapter)
assert weather_info == WeatherInfo.from_dict(fake_weather_info)如果运行测试，会获得：
============================= test session starts ==============================
tests/test_weather_app.py::test_retrieve_weather_using_adapter PASSED [100%]
============================== 1 passed in 0.22s ===============================优点这个方法的优点是可以成功将测试和实现解耦。使用依赖注入dependency injection在测试期间注入一个假的适配器。你也可以在任何时候更换适配器，包括在运行时。这些事情都不会改变任何行为。
缺点缺点就是，因为你在测试中用了假的适配器，如果在实现中往适配器中引入了一个 bug，测试的时候就不会发现。比如说，往 requests 传入了一个有问题的参数，像这样：
def requests_adapter(url: str) -> dict:
resp = requests.get(url, headers=
在生产环境中，适配器会有问题，而且单元测试没办法发现。但是事实是，之前的方法也会有同样的问题。这就是为什么不仅要单元测试，并且总是要集成测试。也就是说，要考虑另一个选项。
3、使用 VCR.py 测试 API
现在终于到了讨论我们最后一个选项了。诚实地说，我也是最近才发现这个。我用模拟mock也很长时间了，而且总是有一些问题。VCR.py 是一个库，它可以简化很多 HTTP 请求的测试。
它的工作原理是将第一次运行测试的 HTTP 交互记录为一个 YAML 文件，叫做 cassette。请求和响应都会被序列化。当第二次运行测试的时候，VCT.py 将拦截对请求的调用，并且返回一个响应。
现在看一下下面如何使用 VCR.py 测试 retrieve_weather：
@vcr.use_cassette()
def test_retrieve_weather_using_vcr(fake_weather_info):
weather_info = retrieve_weather(city="London")
assert weather_info == WeatherInfo.from_dict(fake_weather_info)天呐，就这样？没有设置？@vcr.use_cassette() 是什么？
是的，就这样！没有设置，只要一个 pytest 标注告诉 VCR 去拦截调用，然后保存 cassette 文件。
cassette 文件是什么样？
好问题。这个文件里有很多东西。这是因为 VCR 保存了交互中的所有细节。
interactions:
- request:
body: null
headers:
Accept:
- */
*Accept-Encoding:
- gzip, deflate
Connection:
- keep-alive
User-Agent:
- python-requests/2.24.0
method: GET
uri: https://api.openweathermap.org/data/2.5/weather?q=London&appid=
response:
body:
string: {"coord":{"lon":-0.13,"lat":51.51},"weather":[{"id":800,"main":"Clear","description":"clearsky","icon":"01d"}],"base":"stations","main":{"temp":16.53,"feels_like":15.52,"temp_min":15,"temp_max":17.78,"pressure":1023,"humidity":72},"visibility":10000,"wind":{"speed":2.1,"deg":40},"clouds":{"all":0},"dt":1600420164,"sys":{"type":1,"id":1414,"country":"GB","sunrise":1600407646,"sunset":1600452509},"timezone":3600,"id":2643743,"name":"London","cod":200}
headers:
Access-Control-Allow-Credentials:
- true
Access-Control-Allow-Methods:
- GET, POST
Access-Control-Allow-Origin:
-
*Connection:
- keep-alive
Content-Length:
- 454
Content-Type:
- application/json; charset=utf-8
Date:
- Fri, 18 Sep 2020 10:53:25 GMT
Server:
- openresty
X-Cache-Key:
- /data/2.5/weather?q=london&units=metric
status:
code: 200
message: OK
version: 1确实很多！
真的！好的方面就是你不需要留意它。VCR.py 会为你安排好一切。
优点现在看一下优点，我可以至少列出五个：
没有设置代码。测试仍然是分离的，所以很快。测试是确定的。如果你改了请求，比如说用了错误的 header，测试会失败。没有与代码实现耦合，所以你可以换适配器，而且测试会通过。唯一有关系的东西就是请求必须是一样的。缺点再与模拟相比较，除了避免了错误，还是有一些问题。
如果 API 提供者出于某种原因修改了数据格式，测试仍然会通过。幸运的是，这种情况并不经常发生，而且在这种重大改变之前，API 提供者通常会给他们的 API 提供不同版本。
另一个需要考虑的事情是就地in place端到端end-to-end测试。每次服务器运行的时候，这些测试都会调用。顾名思义，这是一个范围更广、更慢的测试。它们会比单元测试覆盖更多。事实上，并不是每个项目都需要使用它们。所以，就我看来，VCR.py 对于大多数人的需求来说都绰绰有余。
总结
就这么多了。我希望今天你了解了一些有用的东西。测试 API 客户端应用可能会有点吓人。然而，当武装了合适的工具和知识，你就可以驯服这个野兽。
在 我的 Github 上可以找到这个完整的应用。
- Ubuntu 14.04 LTS 已经出来了，我要如何(怎样)升级到Ubuntu 14.04 LTS版本呢？我们可以从镜像或者主要发型版本来升级到最新版本复制代码代码如下:$ uname -mrs复制代码代码如下:Linux 3.2.0-51-generic x86_64复制代码代码如下:$ sudo apt-get update复制代码代码如下:$ sudo do-release-upgratedo-release-upgrate 会运行升级工具。你只需要根据屏幕上的提示操作即可。复制代码代码如下:Checking for a new Ubuntu release复制代码代码如下:sudo do-release-upgrade -d提醒：关于从Ubuntu 13.10 从桌面 升级系统的操作首先，你需要移除所有第三方的二进制驱动，比如 NVIDIA 或者 AMD 显卡驱动。一旦移除后再重启桌面，按住 ALT+F2 并且在 命令框中输入 update-managerupdate manager 会打开并告诉你: New distribution release 14.04 LTS is available(新版的版本 14.04 LTS已经可以使用).只要点击 Upgrade(升级)，然后跟着屏幕上的指示操作即可。注意所有的TLS 桌面版用户需要等到一个叫做 Ubuntu LTS v14.04.1 释放出来才行。假如不想等这个版本，可以在 update-manager中使用 -d 参数来升级。可以通过这种方式，将 Ubuntu 12.04 LTSs 升级到 Ubuntu 14.04 LTS 版本：复制代码代码如下:$ sudo reboot然后确认你是否升级到了最新版本;复制代码代码如下:$ lsb_release -a$ uname -mrs$ tail -f /var/log/app/log/file确认升级到最新版本后，再重新安装第三方的二进制驱动。
- 6450Bi5笔记本电脑的性能与用户评价
- 如何将华硕一体机升级为Windows7操作系统（华硕一体机改Win7教程，详细指导您完成系统升级）
- 主板盲刷BIOS教程（利用主板盲刷BIOS技巧修复电脑系统问题）
- 电脑阅卷中的字体教程（提高电脑阅卷效率的字体选择与设置方法）
- 电脑菜鸟也能轻松重装系统（简明教程带你一步步完成重装，告别电脑烦恼）
- 以一号互联为主题的探索与创新（数字化经济时代下的互联网服务新型模式）
- 芯邦BM2080量产教程（从原理到实践，全面解析芯邦BM2080量产技巧）
- 电脑音乐键盘制作教程——打造你的个人音乐天地（从零开始，教你制作独一无二的电脑音乐键盘！）
- 使用PE硬盘GPT分区教程（简单易懂的分区指南，帮助您轻松操控硬盘）
- 探究绝地求生电脑显示错误登录的原因及解决方法
- 华为电脑系统重装教程（快速了解华为电脑重装系统的步骤及注意事项）
- 固态硬盘系统转移教程（详解固态硬盘迁移方法，轻松转移数据和操作系统）
- 电脑菜鸟也能轻松重装系统（简明教程带你一步步完成重装，告别电脑烦恼）
- 西门子帝度洗衣机的革新性能（功能强大、省时省力，让您的洗衣体验更加便捷高效）
- 神州战神笔记本装机教程
- 以大白菜U盘启动盘系统教程（详解大白菜U盘启动盘的制作和使用，助你快速安装系统）
- 无孔鼠标的创新设计与便利性研究（一触即发，畅游无忧）
- 超能全汉400w的性能源解决方案（解析全新一代超能全汉400w的卓越性能和环保特点）
- 完美备份Ghost教程（详细教你如何进行Ghost备份与恢复）
随便看看
- Copyright © 2025 Powered by 用 Python 测试 API 的三种方式,创站工坊 滇ICP备2023006006号-44sitemap