test: P3-1 第44波单元测试(email_service/session_store) #826

Merged
xiaoxia merged 1 commits from test/unit-test-wave44 into develop 2026-07-24 16:45:47 +08:00
Owner

变更内容

  • 新增 SMTP EmailService 模块测试 18 个(Noop、初始化、send_email 成功/失败/TLS/认证/CC/BCC、验证邮件/重置密码邮件内容、工厂函数)
  • 新增 Redis SessionStore 模块测试 35 个(Noop、配置、save/get/delete/update、refresh_token 映射、用户 session 列表、批量删除、存在性检查、异常处理)
  • 合计 +53 个测试

测试结果

  • 本地全量:4530 passed, 8 skipped
## 变更内容 - 新增 SMTP EmailService 模块测试 18 个(Noop、初始化、send_email 成功/失败/TLS/认证/CC/BCC、验证邮件/重置密码邮件内容、工厂函数) - 新增 Redis SessionStore 模块测试 35 个(Noop、配置、save/get/delete/update、refresh_token 映射、用户 session 列表、批量删除、存在性检查、异常处理) - 合计 +53 个测试 ## 测试结果 - 本地全量:4530 passed, 8 skipped
xiaoxia added 1 commit 2026-07-24 12:57:14 +08:00
test: P3-1 第44波单元测试(email_service/session_store)
CI/CD Pipeline / Check if frontend-only change (pull_request) Successful in 11s
CI/CD Pipeline / Validate - Code Quality (pull_request) Failing after 1m38s
CI/CD Pipeline / Frontend Lint (pull_request) Successful in 36s
CI/CD Pipeline / Validate - Type Check (mypy) (pull_request) Successful in 57s
CI/CD Pipeline / Validate - Migration (alembic) (pull_request) Successful in 1m1s
CI/CD Pipeline / Build Staging API Image (pull_request) Has been skipped
CI/CD Pipeline / Build Staging Web Image (pull_request) Has been skipped
CI/CD Pipeline / Build Staging Worker Image (pull_request) Has been skipped
CI/CD Pipeline / PR Build Web Image (pull_request) Successful in 31s
Preview Deploy / Deploy Preview Environment (pull_request) Failing after 19s
PR Automation / Auto Merge on CI Green + Approved (pull_request) Successful in 45s
CI/CD Pipeline / PR Build API Image (pull_request) Successful in 3m43s
CI/CD Pipeline / Frontend Unit Tests (pull_request) Has been skipped
CI/CD Pipeline / Build Production API Image (pull_request) Has been skipped
CI/CD Pipeline / Build Production Web Image (pull_request) Has been skipped
CI/CD Pipeline / Build Production Worker Image (pull_request) Has been skipped
PR Automation / Auto Approve on CI Green (pull_request) Successful in 3m18s
CI/CD Pipeline / Deploy Staging (Watchtower auto-deploy) (pull_request) Has been skipped
CI/CD Pipeline / Deploy Production (pull_request) Has been skipped
CI/CD Pipeline / Staging E2E Tests (pull_request) Has been skipped
CI/CD Pipeline / Staging API Integration Tests (pull_request) Has been skipped
CI/CD Pipeline / ACR Image Cleanup (pull_request) Has been skipped
CI/CD Pipeline / Production Browser E2E (pull_request) Has been skipped
CI/CD Pipeline / Unit Tests (pull_request) Successful in 2m17s
CI/CD Pipeline / Integration Tests (pull_request) Successful in 2m10s
CI/CD Pipeline / PR Build Worker Image (pull_request) Successful in 7m27s
AI Code Review / AI Code Review (pull_request) Successful in 7m45s
Preview Cleanup / Cleanup Preview Environment (pull_request) Successful in 25s
e5207a4319
Collaborator

代码审查结果 - PR #826

⚠️ 问题(2个需要修改)

  1. tests/unit/test_email_service_smtp.py 第251行:单例测试逻辑错误,无法验证单例模式。

    • 问题描述:测试用例名为 test_singleton_default,但断言使用了 type(svc1) == type(svc2)。这仅验证了两次调用返回的对象类型一致,并未验证是否为同一个实例(单例)。如果工厂函数每次返回一个新的 NoopEmailService() 实例,该测试依然会通过,但这违背了单例模式的初衷。
    • 修改建议:应使用 assert svc1 is svc2 来验证对象身份,确保返回的是同一个实例。
  2. tests/unit/test_redis_session_store.py 第307-311行:模拟了不可能的 Redis 状态,测试逻辑与实际行为冲突。

    • 问题描述:在 test_update_expired_session 中,mock 设置 get 返回了 JSON 数据(意味着 Key 存在),但同时设置 ttl 返回 -2(意味着 Key 不存在)。在真实 Redis 环境中,如果 Key 不存在(TTL 为 -2),get 必定返回 None。这种矛盾的 Mock 状态会导致测试逻辑混乱,无法准确反映代码在真实场景下的行为(例如,如果实现逻辑是先判断 get 结果,该测试可能掩盖错误;如果依赖 ttl 判断,则测试了不存在的分支)。
    • 修改建议:修正 Mock 数据。若要测试“Key 已过期”,应让 get 返回 None;若要测试“Key 存在但 TTL 异常”,应让 ttl 返回 -1(无过期)或正数。通常测试过期场景应模拟 get 返回 None

💡 建议(1个可选)

  1. tests/unit/test_redis_session_store.py 第358-367行side_effect 链条过长,测试脆弱性较高。
    • 具体内容:test_delete_all_user_sessions 中通过 side_effect 硬编码了长达 6 次的 Redis 调用返回顺序。这种写法与内部实现细节(如 get_user_sessionsdelete_session 的具体调用顺序)强耦合。一旦被测代码内部调用顺序发生微调(例如增加了日志记录或改变了查询逻辑),测试就会失败。
    • 修改建议:建议使用 side_effect 接受一个函数,根据传入的参数动态返回值,或者使用更高级的 Mock 工具(如 mock_redis.getwraps 或自定义 Matcher)来解耦测试与实现细节。

格式检查通过 | 逻辑审查需修改 | 性能无明显问题


🤖 由 AI 代码审查机器人自动生成 | 2026-07-24 05:13:24 | 模型:

## 代码审查结果 - PR #826 ### ⚠️ 问题(2个需要修改) 1. **tests/unit/test_email_service_smtp.py 第251行**:单例测试逻辑错误,无法验证单例模式。 - 问题描述:测试用例名为 `test_singleton_default`,但断言使用了 `type(svc1) == type(svc2)`。这仅验证了两次调用返回的对象类型一致,并未验证是否为同一个实例(单例)。如果工厂函数每次返回一个新的 `NoopEmailService()` 实例,该测试依然会通过,但这违背了单例模式的初衷。 - 修改建议:应使用 `assert svc1 is svc2` 来验证对象身份,确保返回的是同一个实例。 2. **tests/unit/test_redis_session_store.py 第307-311行**:模拟了不可能的 Redis 状态,测试逻辑与实际行为冲突。 - 问题描述:在 `test_update_expired_session` 中,mock 设置 `get` 返回了 JSON 数据(意味着 Key 存在),但同时设置 `ttl` 返回 `-2`(意味着 Key 不存在)。在真实 Redis 环境中,如果 Key 不存在(TTL 为 -2),`get` 必定返回 `None`。这种矛盾的 Mock 状态会导致测试逻辑混乱,无法准确反映代码在真实场景下的行为(例如,如果实现逻辑是先判断 `get` 结果,该测试可能掩盖错误;如果依赖 `ttl` 判断,则测试了不存在的分支)。 - 修改建议:修正 Mock 数据。若要测试“Key 已过期”,应让 `get` 返回 `None`;若要测试“Key 存在但 TTL 异常”,应让 `ttl` 返回 -1(无过期)或正数。通常测试过期场景应模拟 `get` 返回 `None`。 ### 💡 建议(1个可选) 1. **tests/unit/test_redis_session_store.py 第358-367行**:`side_effect` 链条过长,测试脆弱性较高。 - 具体内容:`test_delete_all_user_sessions` 中通过 `side_effect` 硬编码了长达 6 次的 Redis 调用返回顺序。这种写法与内部实现细节(如 `get_user_sessions` 和 `delete_session` 的具体调用顺序)强耦合。一旦被测代码内部调用顺序发生微调(例如增加了日志记录或改变了查询逻辑),测试就会失败。 - 修改建议:建议使用 `side_effect` 接受一个函数,根据传入的参数动态返回值,或者使用更高级的 Mock 工具(如 `mock_redis.get` 的 `wraps` 或自定义 Matcher)来解耦测试与实现细节。 --- ✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能无明显问题 --- <sub>🤖 由 AI 代码审查机器人自动生成 | 2026-07-24 05:13:24 | 模型: </sub> <!-- AI_CODE_REVIEW_AUTO_COMMENT -->
xiaoxia merged commit 0bfb57813f into develop 2026-07-24 16:45:47 +08:00
xiaoxia deleted branch test/unit-test-wave44 2026-07-24 16:45:47 +08:00

🗑️ 预览环境已清理

PR #826 已关闭或合并,对应的预览环境已被清理。

如有需要,可以重新打开 PR 来重新生成预览环境。

🗑️ **预览环境已清理** PR #826 已关闭或合并,对应的预览环境已被清理。 > 如有需要,可以重新打开 PR 来重新生成预览环境。
Sign in to join this conversation.