企业官网建设流程全解析

1. 项目概述：为什么我们需要一个完整的Twitter API测试方案？

如果你正在用Python开发一个与Twitter API交互的应用，无论是自动化发布、数据抓取还是舆情分析，你大概率会遇到一个头疼的问题：测试怎么写？直接调用真实的Twitter API进行测试，不仅会消耗有限的API请求配额，还可能因为网络波动、API限流甚至账号被封禁而导致测试结果不稳定。更麻烦的是，测试数据（比如你发的测试推文）会污染你的账号时间线。所以，一个健壮的、隔离的、可重复的测试策略，不是“锦上添花”，而是项目能持续迭代、团队能安心协作的“生命线”。

我接手过不少从“脚本”演变成“项目”的Twitter机器人，早期都是直接python main.py看输出，一旦API返回个错误码，就得靠print大法一点点猜。后来引入了测试，但往往只停留在用真实API跑几个简单场景的“集成测试”，导致开发速度慢，不敢重构，每次跑测试都提心吊胆。直到我们系统地构建了包含单元测试和集成测试的分层策略，开发体验才有了质的飞跃。今天，我就把这个完整的方案拆开揉碎了讲给你听，从设计思路到每一行代码的避坑细节，目标是让你能直接“抄作业”，构建起自己项目的测试护城河。

这个方案的核心是“分层”和“模拟”。我们将测试分为单元测试（隔离测试单个函数或类）和集成测试（测试多个模块协同工作，包括与外部API的交互）。单元测试追求极致的速度和隔离性，所以我们会大量使用unittest.mock来模拟Twitter API的响应；而集成测试则需要谨慎地、有控制地触碰真实API，验证整个链条是否畅通。我们会用到pytest作为测试框架，因为它比Python自带的unittest更灵活、功能更强大，社区插件生态也更丰富。

2. 测试策略的整体设计与核心思路

2.1 为什么是分层测试策略？

很多开发者对测试的认知是“写个脚本调用一下API，看看能不能通”。这其实是一种非常原始且脆弱的集成测试。分层测试策略的价值在于，它像给项目搭建了一个多层次的质量检测网：

1. 单元测试（最底层、最快）：负责验证你代码中每一个“零件”（函数、类方法）的逻辑是否正确。例如，一个解析Twitter API返回的JSON数据、提取用户名的函数。它的特点是快（毫秒级）和稳定（不依赖网络、数据库等外部服务）。通过模拟（Mocking），我们可以让这个函数在任何环境下都返回我们预设的数据，从而专注测试其内部逻辑。这层网孔最密，能抓住大部分低级错误（如边界条件处理、空值判断）。

2. 集成测试（中间层、更真实）：负责验证这些“零件”组装在一起后能否协同工作，特别是与外部服务（Twitter API）的交互是否正确。例如，你的TwitterClient类能否成功构建请求头、发送HTTP请求、并处理API的响应（无论是成功还是错误）。这层测试会部分触及真实世界，因此比单元测试慢，但也更能发现模块间接口不匹配、认证错误、数据格式误解等问题。

3. （可选）端到端测试（最上层、最真实）：模拟真实用户操作整个流程，例如从读取配置、认证、发推、到验证推文是否成功发布。这层测试成本最高，也最不稳定，通常只在关键流程或发布前进行。我们今天的方案主要聚焦在前两层，因为它们性价比最高，是测试体系的基石。

采用分层策略，最大的好处是快速反馈和问题定位。当集成测试失败时，如果对应的单元测试是通过的，你几乎可以立刻断定问题是出在模块间的集成、网络通信或API本身，而不是内部逻辑错误，这能极大缩短调试时间。

2.2 工具选型：Pytest + Requests-Mock + Tweepy (示例)

我们将使用以下工具栈，这也是Python生态中经过大量项目验证的黄金组合：

• 测试框架：Pytest。它提供了更简洁的断言语法（直接用assert）、强大的夹具（Fixtures）系统、丰富的插件（如覆盖率报告pytest-cov、并行测试pytest-xdist），并且能兼容unittest风格的测试用例。它的pytest-mock插件让模拟变得异常简单。
• HTTP请求模拟：Requests-Mock。如果你的项目使用流行的requests库来调用Twitter API，那么requests-mock是单元测试的神器。它可以在requests库的层面拦截HTTP请求，直接返回你预设的响应，完全绕过网络。比直接Mock某个函数更彻底。
• Twitter API客户端库（示例）：Tweepy。许多Python项目使用Tweepy这个封装良好的库来与Twitter API交互。我们的测试方案同样适用于它，核心思想是模拟Tweepy提供的方法，而不是直接模拟requests。如果你用的是自封装的客户端，原理相通。
• 测试覆盖率：pytest-cov。衡量测试是否充分的重要（但不是唯一）指标。它能告诉你代码的哪些行、哪些分支被测试执行过，帮助发现测试盲区。

注意：选择requests-mock还是pytest-mock来模拟Tweepy，取决于你想在哪个层次进行隔离。模拟层次越高（如直接模拟Tweepy的API类），测试与Tweepy内部实现的耦合度就越高，但写起来可能更简单。模拟层次越低（如用requests-mock），测试就更接近真实的网络交互，对Tweepy库本身的更新更不敏感，但设置可能稍复杂。本文会展示两种常见模式。

2.3 项目目录结构规划

一个清晰的目录结构是测试可维护性的基础。建议如下：

your_twitter_project/ ├── src/ # 源代码目录 │ ├── __init__.py │ ├── twitter_client.py # 封装Twitter API交互的核心类 │ ├── models.py # 数据模型（如Tweet, User） │ └── utils.py # 工具函数（如日期处理、文本清洗） ├── tests/ # 测试目录 │ ├── __init__.py │ ├── conftest.py # Pytest的共享夹具（Fixtures）定义处 │ ├── unit/ # 单元测试 │ │ ├── __init__.py │ │ ├── test_twitter_client.py │ │ └── test_utils.py │ └── integration/ # 集成测试 │ ├── __init__.py │ └── test_twitter_client_integration.py ├── .env.example # 环境变量示例文件（包含API_KEY等占位符） ├── pytest.ini # Pytest配置文件 └── requirements.txt # 项目依赖

关键点：

• 使用src布局，避免导入混乱。
• tests目录镜像src的结构，方便查找对应测试。
• conftest.py是pytest的魔力所在，这里定义的夹具（如模拟的客户端、测试用的API响应数据）可以被所有测试文件使用。
• 严格区分unit和integration文件夹，方便用pytest命令单独运行某一类测试（如pytest tests/unit）。

3. 单元测试实战：彻底隔离外部依赖

单元测试的目标是“快”和“稳”。我们绝不允许一次网络超时导致整个测试套件失败。因此，模拟（Mocking）是我们的核心武器。

3.1 测试纯粹的工具函数

我们从最简单的开始。假设在src/utils.py中有一个清理推文文本的函数：

# src/utils.py def clean_tweet_text(text: str) -> str: """移除推文中的URL和多余空白字符。""" if not text: return "" # 一个简单的URL移除逻辑（示例用，实际可能更复杂） import re text = re.sub(r'https?://\S+', '', text) text = ' '.join(text.split()) # 合并多余空白 return text.strip()

对应的单元测试tests/unit/test_utils.py会非常直接：

# tests/unit/test_utils.py from src.utils import clean_tweet_text def test_clean_tweet_text_removes_url(): """测试URL被正确移除。""" input_text = "Check this out https://example.com and this http://foo.bar" expected = "Check this out and this" assert clean_tweet_text(input_text) == expected def test_clean_tweet_text_handles_empty_string(): """测试处理空字符串。""" assert clean_tweet_text("") == "" assert clean_tweet_text(None) == "" # 假设我们希望处理None def test_clean_tweet_text_collapses_whitespace(): """测试合并多余空白字符。""" assert clean_tweet_text("Hello world !") == "Hello world !"

这里没有任何模拟，因为函数不依赖外部服务。我们只关心输入/输出。注意我们测试了正常情况、边界情况（空字符串、None）和特定功能（移除URL、合并空白）。这就是单元测试的典型思维。

3.2 测试Twitter API客户端（使用unittest.mock）

现在进入核心部分：测试封装了Twitter API调用的类。假设我们有一个简化的客户端TwitterClient，它使用Tweepy。

首先，看源码src/twitter_client.py：

# src/twitter_client.py import tweepy from typing import Optional from .models import Tweet class TwitterClient: def __init__(self, api_key: str, api_secret: str, access_token: str, access_secret: str): """初始化Tweepy客户端。""" auth = tweepy.OAuthHandler(api_key, api_secret) auth.set_access_token(access_token, access_secret) self.api = tweepy.API(auth, wait_on_rate_limit=True) def post_tweet(self, text: str) -> Optional[Tweet]: """发布一条推文。返回Tweet对象或None。""" if not text or len(text) > 280: raise ValueError("推文文本无效或超过长度限制") try: # 调用Tweepy的update_status方法 status = self.api.update_status(status=text) return Tweet(id=status.id, text=status.text, created_at=status.created_at) except tweepy.TweepyException as e: print(f"发布推文失败: {e}") return None

我们要测试post_tweet方法，但绝不能真的去发推。因此，我们需要模拟掉self.api.update_status这个外部调用。

使用pytest-mock（它提供了一个mocker夹具）来编写单元测试tests/unit/test_twitter_client.py：

# tests/unit/test_twitter_client.py import pytest from unittest.mock import Mock from src.twitter_client import TwitterClient from src.models import Tweet def test_post_tweet_success(mocker): """模拟成功发布推文。""" # 1. 模拟Tweepy的API对象及其update_status方法 mock_status = Mock() mock_status.id = 1234567890 mock_status.text = "Hello, unit test!" mock_status.created_at = "2023-10-27 10:00:00" mock_api = Mock() mock_api.update_status = Mock(return_value=mock_status) # 2. 在初始化TwitterClient后，将其内部的api属性替换为我们的mock对象 # 使用mocker.patch.object来替换特定实例的属性 client = TwitterClient("dummy_key", "dummy_secret", "dummy_token", "dummy_secret") mocker.patch.object(client, 'api', mock_api) # 3. 执行测试 result = client.post_tweet("Hello, unit test!") # 4. 验证断言 assert isinstance(result, Tweet) assert result.id == 1234567890 assert result.text == "Hello, unit test!" # 验证update_status方法被以正确的参数调用了一次 mock_api.update_status.assert_called_once_with(status="Hello, unit test!") def test_post_tweet_invalid_text_raises_valueerror(): """测试传入无效文本时抛出ValueError。""" client = TwitterClient("dummy_key", "dummy_secret", "dummy_token", "dummy_secret") # 注意：这里不需要模拟api，因为方法会在调用api之前就抛出异常 with pytest.raises(ValueError, match="推文文本无效或超过长度限制"): client.post_tweet("") # 空文本 with pytest.raises(ValueError): client.post_tweet("x" * 281) # 超长文本 def test_post_tweet_api_failure_returns_none(mocker): """模拟Tweepy调用失败，返回None。""" mock_api = Mock() mock_api.update_status = Mock(side_effect=tweepy.TweepyException("API Error")) client = TwitterClient("dummy_key", "dummy_secret", "dummy_token", "dummy_secret") mocker.patch.object(client, 'api', mock_api) result = client.post_tweet("This will fail") assert result is None mock_api.update_status.assert_called_once_with(status="This will fail")

关键技巧与避坑指南：

1. mocker夹具：pytest-mock提供的mocker是unittest.mock的增强版，与pytest集成得更好。它会在每个测试函数结束后自动清理所有模拟，避免测试间相互污染。
2. 模拟的粒度：我们模拟的是client.api这个实例属性，而不是整个TwitterClient类或Tweepy模块。这样更精准，只隔离了我们想隔离的外部依赖。
3. assert_called_once_with：这是Mock对象最强大的功能之一。它不仅能验证方法是否被调用，还能验证调用时的参数是否完全符合预期。这能捕捉到许多因参数传递错误导致的bug。
4. side_effect：当你想模拟一个异常，或者让同一个Mock对象在多次调用中返回不同值时，就用side_effect。它可以是一个异常类、一个异常实例，或者一个可迭代对象（每次调用返回下一个值）。
5. 不要过度模拟：在这个测试中，我们只模拟了update_status。TwitterClient.__init__中的tweepy.OAuthHandler和tweepy.API初始化也被执行了，但这没关系，因为它们只是创建了一些对象，并没有进行真正的网络调用（除非它们内部有复杂的逻辑，那可能需要进一步模拟）。单元测试的哲学是：只模拟有副作用（I/O、网络、数据库）或不确定性的部分。

3.3 使用Requests-Mock进行更低层次的模拟

如果你的客户端是直接使用requests库，或者你想更彻底地控制HTTP层面的交互，requests-mock是更好的选择。假设我们有一个更底层的TwitterAPIClient：

# src/twitter_client_raw.py import requests import os class TwitterAPIClient: BASE_URL = "https://api.twitter.com/2" def __init__(self, bearer_token: str): self.session = requests.Session() self.session.headers.update({"Authorization": f"Bearer {bearer_token}"}) def get_user(self, username: str): url = f"{self.BASE_URL}/users/by/username/{username}" response = self.session.get(url) response.raise_for_status() # 如果状态码不是2xx，抛出HTTPError return response.json()

对应的单元测试可以使用requests-mock：

# tests/unit/test_twitter_client_raw.py import pytest import requests_mock from src.twitter_client_raw import TwitterAPIClient def test_get_user_success(): client = TwitterAPIClient("dummy_token") expected_response = { "data": { "id": "123", "name": "Test User", "username": "testuser" } } # 使用requests_mock的上下文管理器 with requests_mock.Mocker() as m: # 匹配特定的URL，并返回我们预设的JSON响应和状态码 m.get("https://api.twitter.com/2/users/by/username/testuser", json=expected_response, status_code=200) result = client.get_user("testuser") assert result == expected_response # 还可以验证请求头是否正确 assert m.last_request.headers['Authorization'] == 'Bearer dummy_token' def test_get_user_not_found(): client = TwitterAPIClient("dummy_token") error_response = {"errors": [{"detail": "User not found"}]} with requests_mock.Mocker() as m: m.get("https://api.twitter.com/2/users/by/username/nonexistent", json=error_response, status_code=404) # 验证是否按预期抛出了异常 with pytest.raises(requests.exceptions.HTTPError) as exc_info: client.get_user("nonexistent") assert exc_info.value.response.status_code == 404

requests-mock的优势在于，它直接在HTTP请求层进行拦截，你可以精确控制返回的状态码、响应头、响应体，并且能验证发出的请求是否符合预期。这对于测试重试逻辑、错误处理、请求参数构建等场景非常有用。

4. 集成测试实战：有控制地触碰真实API

单元测试保证了我们的代码逻辑正确，但代码和真实的Twitter API之间是否能正常“握手”？我们的认证信息是否正确？我们对API响应格式的理解有没有偏差？这就需要集成测试来验证。

集成测试的关键是“有控制”和“隔离”。我们虽然使用真实API，但要尽量降低对真实账号和数据的影响。

4.1 集成测试的准备工作与环境隔离

1. 使用测试专用账号或应用：如果条件允许，最好为集成测试单独创建一个Twitter开发者账号和应用。这样即使测试产生垃圾数据或触发限流，也不会影响主业务账号。

2. 环境变量管理：绝对不要将API密钥硬编码在测试代码中！使用python-dotenv从.env文件加载，或在CI/CD环境中设置环境变量。

   # tests/conftest.py import os import pytest from dotenv import load_dotenv from src.twitter_client import TwitterClient load_dotenv() # 加载项目根目录下的.env文件 @pytest.fixture(scope="session") def twitter_client(): """提供一个已认证的真实Twitter客户端夹具，供所有集成测试使用。""" api_key = os.getenv("TWITTER_API_KEY") api_secret = os.getenv("TWITTER_API_SECRET") access_token = os.getenv("TWITTER_ACCESS_TOKEN") access_secret = os.getenv("TWITTER_ACCESS_SECRET") if not all([api_key, api_secret, access_token, access_secret]): pytest.skip("缺少Twitter API认证信息，跳过集成测试") client = TwitterClient(api_key, api_secret, access_token, access_secret) # 可以在这里添加一个快速的连通性测试，比如获取当前用户信息 # 如果失败，则跳过所有集成测试 try: client.api.verify_credentials() # Tweepy的方法，验证凭证 print("Twitter API认证成功，开始集成测试。") except Exception as e: pytest.skip(f"Twitter API认证失败: {e}") return client

   这个twitter_client夹具的作用域是session，意味着在整个测试会话中只创建一次，所有集成测试共享同一个客户端实例，节省认证开销。

3. 测试数据管理：

   • 创建：在测试开始时，创建专用的测试数据（如一条特定内容的推文）。
   • 清理：在测试结束后（或下一个测试开始前），务必清理这些数据。使用pytest的setup_method/teardown_method或夹具的yield模式来实现。
   • 幂等性：测试本身要设计成可重复运行。例如，删除推文前先检查它是否存在。

4.2 编写一个安全的集成测试用例

我们编写一个集成测试，验证“发布推文”和“删除推文”这个完整流程。注意，我们发布的内容要具有唯一性，便于后续查找和清理。

# tests/integration/test_twitter_client_integration.py import pytest import time from tweepy import TweepyException class TestTwitterClientIntegration: """集成测试类。使用真实的Twitter API。""" @pytest.fixture(autouse=True) def setup_and_teardown(self, twitter_client): """每个测试方法前后自动执行。""" self.client = twitter_client self.test_tweet_id = None # 用于存储测试创建的推文ID yield # 这里是测试方法执行的地方 # 测试方法执行后，清理测试数据 self._cleanup_test_tweet() def _cleanup_test_tweet(self): """清理测试推文。""" if self.test_tweet_id: try: self.client.api.destroy_status(self.test_tweet_id) print(f"已清理测试推文: {self.test_tweet_id}") except TweepyException as e: print(f"清理推文 {self.test_tweet_id} 时失败（可能已被删除）: {e}") finally: self.test_tweet_id = None def test_post_and_delete_tweet(self): """集成测试：发布一条推文，并验证其存在，然后删除。""" # 1. 发布推文 unique_text = f"集成测试推文 - {time.time()}" # 使用时间戳确保唯一性 print(f"准备发布推文: '{unique_text}'") tweet = self.client.post_tweet(unique_text) # 2. 断言发布成功 assert tweet is not None assert tweet.id is not None assert unique_text in tweet.text self.test_tweet_id = tweet.id # 记录ID以供清理 # 3. （可选）通过API获取刚发布的推文，验证数据一致性 # 注意：Twitter API v2的推文获取可能有延迟，v1.1的`get_status`更即时。 try: # 使用Tweepy v1.1接口获取状态 fetched_status = self.client.api.get_status(tweet.id, tweet_mode='extended') assert fetched_status.text == unique_text print("成功获取并验证新推文。") except TweepyException as e: # 对于v2 API，获取推文可能更复杂，这里我们仅记录警告。 print(f"警告：无法立即获取推文进行二次验证（可能为API v2延迟）: {e}") # 4. 清理工作由teardown fixture自动完成 # 但我们也可以在这里显式清理，并验证删除成功 self.client.api.destroy_status(tweet.id) self.test_tweet_id = None # 避免teardown重复删除 # 5. 验证推文已被删除（尝试获取应抛出404） with pytest.raises(TweepyException) as exc_info: self.client.api.get_status(tweet.id) # 通常，删除后获取会返回404错误。根据Tweepy的具体异常判断。 assert "404" in str(exc_info.value) or "Not Found" in str(exc_info.value) print("推文删除验证成功。")

集成测试的要点与陷阱：

1. 唯一性标识：使用time.time()或uuid来生成唯一的推文内容，避免多次运行测试时因内容重复而冲突（Twitter可能不允许发布完全相同的推文）。
2. 清理的可靠性：teardown中的清理操作必须放在try...except块中。因为测试可能中途失败，导致推文并未成功创建，此时清理会抛出异常，进而掩盖原始测试失败的原因。捕获并打印异常信息是更稳妥的做法。
3. API速率限制：即使集成测试用例不多，也要注意Twitter API的速率限制。可以在TwitterClient初始化时设置wait_on_rate_limit=True（如我们之前所做），或者在测试套件中全局添加延迟time.sleep()。更好的做法是，将集成测试标记为“慢速测试”，在CI中与单元测试分开运行。
4. 网络与超时：集成测试受网络环境影响。要为API调用设置合理的超时（可在TwitterClient中配置），并在测试中处理可能的超时异常。
5. 测试验证点：集成测试的断言应聚焦在“集成”点上。例如，我们不仅断言post_tweet方法返回了一个Tweet对象，还通过另一个API调用（get_status）来验证这条数据确实存在于Twitter平台上，验证了“写-读”一致性。

4.3 使用Pytest标记管理测试

为了能灵活地运行不同类型的测试，我们使用pytest的标记（mark）功能。

在pytest.ini中注册标记：

# pytest.ini [pytest] markers = unit: 标记单元测试。 integration: 标记集成测试（需要网络和外部API）。 slow: 标记运行缓慢的测试。

在测试文件中标记：

# tests/unit/test_xxx.py import pytest @pytest.mark.unit def test_something(): ... # tests/integration/test_xxx.py import pytest @pytest.mark.integration @pytest.mark.slow class TestTwitterClientIntegration: ...

运行命令：

• 只运行单元测试：pytest -m unit
• 只运行集成测试：pytest -m integration
• 排除慢速测试：pytest -m "not slow"
• 在CI中，可以配置先快速运行所有单元测试，只有通过后才运行集成测试。

5. 高级技巧与常见问题排查

5.1 模拟（Mock）的进阶用法

1. 模拟链式调用：有时你会遇到obj.method_a().method_b()这样的链式调用。模拟时需要创建多个Mock对象。

   mock_response = Mock() mock_response.method_b.return_value = "final_result" mock_obj = Mock() mock_obj.method_a.return_value = mock_response assert my_function(mock_obj) == "final_result" mock_obj.method_a.assert_called_once() mock_response.method_b.assert_called_once()

2. 模拟上下文管理器（with语句）：例如模拟open()或某些数据库连接。

   mock_file = Mock() mock_file.read.return_value = "file contents" mock_opener = Mock() mock_opener.__enter__.return_value = mock_file mock_opener.__exit__.return_value = None mocker.patch('builtins.open', return_value=mock_opener) # 现在 with open(...) as f: f.read() 将返回 "file contents"

3. 使用autospec提高模拟安全性：mocker.patch(target, autospec=True)会创建一个与被模拟对象具有相同属性和方法的Mock，如果你错误地调用了一个不存在的方法，它会抛出AttributeError，这能及早发现接口变更导致的错误。

5.2 集成测试中的常见“坑”与解决方案

1. 坑：测试数据清理不彻底，导致后续测试失败。

   • 方案：如前所述，使用夹具的yield或addfinalizer确保清理代码一定执行。为测试数据添加唯一性标签，并在teardown中尝试清理所有带有该标签的数据（例如，搜索并删除所有包含[TEST]的推文）。

2. 坑：API速率限制导致测试套件整体超时或失败。

   • 方案：
     • 在客户端启用wait_on_rate_limit。
     • 将集成测试设计为“只读”为主。例如，多测试get_user、get_timeline，少测试post_tweet、delete_tweet。
     • 使用pytest.mark.flaky标记可能因限流失败的测试，并配置重试逻辑（通过pytest-rerunfailures插件）。

3. 坑：测试环境与生产环境的API密钥或权限不同。

   • 方案：在conftest.py的夹具中做前置检查，如果缺少必要的环境变量或认证失败，则用pytest.skip()跳过整个集成测试套件，并给出明确的提示信息。这比让测试因KeyError而崩溃更友好。

4. 坑：Twitter API版本差异。v1.1和v2的接口、响应格式、速率限制都不同。

   • 方案：在测试文件和客户端代码中明确标注所使用的API版本。可以为不同版本编写不同的测试夹具或客户端类。在模拟响应数据时，务必使用对应版本的真实响应样本。

5.3 测试覆盖率与持续集成

1. 生成覆盖率报告：

   # 运行测试并生成终端报告 pytest --cov=src --cov-report=term-missing # 生成HTML报告，便于详细查看 pytest --cov=src --cov-report=html

   打开生成的htmlcov/index.html，你可以直观地看到哪些代码行被测试覆盖了（绿色），哪些没有（红色）。不要盲目追求100%覆盖率，但95%以上是一个健康项目的良好指标。重点检查核心业务逻辑的覆盖情况。

2. 集成到CI/CD（如GitHub Actions）： 在你的.github/workflows/test.yml中，可以配置如下步骤：

   jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: { python-version: '3.10' } - name: Install dependencies run: pip install -r requirements.txt pytest pytest-cov - name: Run unit tests with coverage run: pytest tests/unit -v --cov=src --cov-report=xml --cov-fail-under=90 - name: Run integration tests (conditionally) if: github.event_name == 'push' && github.ref == 'refs/heads/main' # 仅在主分支推送时运行 env: TWITTER_API_KEY: ${{ secrets.TWITTER_API_KEY }} TWITTER_API_SECRET: ${{ secrets.TWITTER_API_SECRET }} # ... 其他密钥 run: pytest tests/integration -v -m integration

   这样，每次推送代码都会运行快速的单元测试并检查覆盖率，只有合并到主分支时才会运行更耗时的集成测试，既保证了效率又确保了质量。

构建一个完整的Python Twitter API测试体系，初期投入的时间会在项目维护、团队协作和代码质量上带来十倍百倍的回报。从今天起，为你下一个与Twitter API交互的脚本，加上单元测试的“安全网”和集成测试的“验收门”吧。当你能够自信地重构代码，并且一键运行测试后就能放心部署时，你会感谢当初决定系统化做测试的自己。