coze-loop作品集：10个典型FastAPI依赖注入代码的可测试性增强

你是不是也遇到过这种情况？写FastAPI应用时，依赖注入用得很顺手，代码看起来也挺整洁，但一到写单元测试就头疼了——那些依赖项层层嵌套，Mock起来费时费力，测试代码比业务逻辑还复杂。

今天，我就用coze-loop这个AI代码优化器，带你一起看看如何提升FastAPI依赖注入代码的可测试性。我会展示10个真实场景的代码优化案例，每个案例都包含优化前后的对比，以及coze-loop给出的专业优化思路。

1. 什么是coze-loop？

简单来说，coze-loop是一个AI驱动的代码优化助手。它基于Ollama本地大模型框架，专门帮开发者优化代码质量。

你只需要：

  1. 粘贴一段代码
  2. 选择一个优化目标（比如“增强代码可读性”、“提高运行效率”）
  3. 点击优化按钮

几秒钟后，AI就会给你一份详细的优化报告，包括优化后的代码和每一步的修改说明。

对于今天的话题——提升FastAPI依赖注入的可测试性——coze-loop能帮我们识别那些难以测试的代码模式，并给出更清晰、更易于测试的重构方案。

2. 为什么FastAPI依赖注入的可测试性这么重要？

在深入案例之前，我们先聊聊为什么要在意这个。

依赖注入是FastAPI的一大亮点，它让代码结构更清晰，但如果不注意写法，很容易造成“测试地狱”：

  • 紧耦合：业务逻辑和具体实现绑得太死，换不掉
  • 隐藏依赖：依赖关系不透明，测试时不知道要Mock什么
  • 状态污染：测试之间相互影响，结果不稳定

好的可测试性意味着：

  • 单元测试写起来快，不费脑
  • 测试用例稳定可靠，不随机失败
  • 代码重构时，测试能给你信心

下面这10个案例，就是从“难测试”到“易测试”的蜕变过程。

3. 案例展示：10个代码优化实录

我将这些案例分成了几个常见的问题类别，你可以看看自己的代码里有没有类似的情况。

3.1 类别一：依赖项直接在函数内部创建

这是最典型的“难测试”模式，依赖在函数里硬编码，外部根本无法干预。

案例1：直接在路由函数中实例化服务

# 优化前 - 难以测试的版本
from fastapi import FastAPI
import some_service_module

app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    # 问题：服务在函数内部创建，无法在测试中替换
    service = some_service_module.ItemService(database_url="hardcoded_url")
    result = service.get_item(item_id)
    return result

把这段代码丢进coze-loop，选择“增强代码可读性”（实际上也大幅提升了可测试性），得到了这样的优化结果：

# 优化后 - 易于测试的版本
from fastapi import FastAPI, Depends
from typing import Protocol
import some_service_module

app = FastAPI()

# 使用Protocol定义接口，明确依赖契约
class ItemServiceProtocol(Protocol):
    def get_item(self, item_id: int):
        ...

# 依赖注入函数：创建服务的逻辑集中在这里
def get_item_service() -> ItemServiceProtocol:
    return some_service_module.ItemService(database_url="hardcoded_url")

@app.get("/items/{item_id}")
async def read_item(
    item_id: int,
    service: ItemServiceProtocol = Depends(get_item_service)  # 依赖通过参数注入
):
    result = service.get_item(item_id)
    return result

coze-loop的优化思路：

  1. 引入协议（Protocol）：明确定义了ItemService应该有什么方法，这样无论是真实服务还是测试用的Mock，只要符合这个协议就能用。
  2. 提取依赖创建逻辑：把创建服务的代码移到单独的get_item_service函数中，路由函数只声明需要什么，不关心怎么来的。
  3. 使用FastAPI的Depends：这是FastAPI推荐的方式，依赖关系一目了然。

测试变得多简单： 现在你写测试时，可以轻松替换掉get_item_service这个依赖，换成你控制的Mock服务。

3.2 类别二：全局状态和配置散落各处

配置信息硬编码，或者用全局变量，会让测试非常脆弱。

案例2：配置值散落在多个依赖中

# 优化前
import os
from fastapi import FastAPI, Depends
from some_db_module import DatabaseClient

app = FastAPI()

# 多个地方重复读取同样的配置
def get_db_connection():
    db_host = os.getenv("DB_HOST", "localhost")  # 配置读取分散
    db_port = os.getenv("DB_PORT", "5432")
    return DatabaseClient(host=db_host, port=db_port)

def get_cache_client():
    cache_host = os.getenv("REDIS_HOST", "localhost")  # 另一个地方又读一遍
    cache_port = os.getenv("REDIS_PORT", "6379")
    return CacheClient(host=cache_host, port=cache_port)

@app.get("/data")
async def get_data(
    db=Depends(get_db_connection),
    cache=Depends(get_cache_client)
):
    # 使用db和cache...
    pass

coze-loop的优化方案是引入配置集中管理：

# 优化后
from pydantic import BaseSettings
from fastapi import FastAPI, Depends
from typing import Optional
from some_db_module import DatabaseClient
from some_cache_module import CacheClient

class Settings(BaseSettings):
    db_host: str = "localhost"
    db_port: str = "5432"
    redis_host: str = "localhost"
    redis_port: str = "6379"
    
    class Config:
        env_file = ".env"

app = FastAPI()
settings = Settings()  # 配置单例

# 依赖函数现在接收配置作为参数（或从闭包中访问）
def get_db_connection():
    return DatabaseClient(
        host=settings.db_host,
        port=settings.db_port
    )

def get_cache_client():
    return CacheClient(
        host=settings.redis_host,
        port=settings.redis_port
    )

@app.get("/data")
async def get_data(
    db=Depends(get_db_connection),
    cache=Depends(get_cache_client)
):
    # 使用db和cache...
    pass

优化带来的测试优势： 测试时，你可以轻松创建一个测试专用的Settings实例，或者直接Mock settings对象，所有依赖都会自动使用测试配置。

3.3 类别三：复杂的依赖链难以Mock

当依赖项本身又依赖其他服务时，测试就像剥洋葱，一层又一层。

案例3：多层嵌套的依赖关系

# 优化前
def get_redis():
    return RedisClient()

def get_cache(redis=Depends(get_redis)):  # 依赖链：cache依赖redis
    return CacheService(redis)

def get_repository(cache=Depends(get_cache)):  # repository依赖cache
    return ItemRepository(cache)

def get_service(repo=Depends(get_repository)):  # service依赖repository
    return ItemService(repo)

@app.get("/items")
async def get_items(service=Depends(get_service)):  # 路由依赖service
    return service.list_items()

测试这个路由，你需要Mock一整条链！coze-loop建议我们简化依赖链，或者提供“短路”机制：

# 优化后
def get_redis():
    return RedisClient()

def get_cache(redis=Depends(get_redis)):
    return CacheService(redis)

def get_repository(
    cache: Optional[CacheService] = None  # 改为可选参数
):
    if cache is None:
        cache = CacheService(RedisClient())  # 有默认创建逻辑
    return ItemRepository(cache)

# 关键：提供一个“测试专用”的依赖项创建方式
def get_repository_for_testing(cache_mock: CacheService):
    """专门用于测试的依赖覆盖函数"""
    def override_get_repository():
        return ItemRepository(cache_mock)
    return override_get_repository

@app.get("/items")
async def get_items(service=Depends(get_service)):
    return service.list_items()

测试技巧： 现在你可以用app.dependency_overrides来替换整个依赖链中的任意一环，而不需要Mock每一层。

3.4 类别四：副作用隐藏在依赖中

依赖项偷偷做了些事情（比如写日志、发邮件），测试时很难验证。

案例4：依赖项包含隐藏的副作用

# 优化前
def get_email_service():
    service = EmailService()
    service.connect()  # 隐藏的副作用：建立连接
    return service

@app.post("/notify")
async def send_notification(
    email_service=Depends(get_email_service)
):
    # 发送邮件...
    email_service.send("user@example.com", "Hello!")

coze-loop指出，应该把副作用分离，让依赖只返回“就绪”的对象：

# 优化后
def create_email_service():
    """创建但不初始化"""
    return EmailService()

def get_email_service(service: EmailService = Depends(create_email_service)):
    """依赖项：负责初始化"""
    service.connect()  # 初始化动作在这里
    return service

# 或者更清晰的方式：使用上下文管理器
from contextlib import contextmanager

@contextmanager
def email_service_context():
    service = EmailService()
    try:
        service.connect()
        yield service
    finally:
        service.disconnect()

def get_email_service():
    with email_service_context() as service:
        yield service

@app.post("/notify")
async def send_notification(
    email_service=Depends(get_email_service)
):
    email_service.send("user@example.com", "Hello!")

为什么这样更好测： 现在你可以单独测试create_email_service（创建）和连接逻辑，也可以轻松Mock一个已经连接好的服务。

3.5 类别五：依赖项与业务逻辑耦合过紧

业务规则和依赖实现混在一起，换个数据库就得改业务代码。

案例5：业务逻辑中直接调用特定数据库的方法

# 优化前
def get_user(user_id: int, db=Depends(get_db)):
    # 业务逻辑和SQL语句耦合
    user = db.execute("SELECT * FROM users WHERE id = ?", (user_id,))
    if user["status"] == "inactive":  # 业务规则
        raise HTTPException(status_code=400, detail="User inactive")
    return user

coze-loop建议引入仓储模式，分离关注点：

# 优化后
# 首先定义仓储接口
class UserRepository:
    def get_user(self, user_id: int):
        raise NotImplementedError

# SQLite实现
class SQLiteUserRepository(UserRepository):
    def __init__(self, db):
        self.db = db
    
    def get_user(self, user_id: int):
        return self.db.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# 依赖项
def get_user_repository(db=Depends(get_db)):
    return SQLiteUserRepository(db)

# 业务逻辑现在只依赖接口
def get_user(
    user_id: int,
    repo: UserRepository = Depends(get_user_repository)
):
    user = repo.get_user(user_id)  # 不关心具体实现
    if user["status"] == "inactive":
        raise HTTPException(status_code=400, detail="User inactive")
    return user

测试的便利： 你可以创建一个MockUserRepository，完全控制它返回什么数据，从而专注测试业务逻辑本身。

4. coze-loop的优化模式总结

通过这10个案例（这里展示了5个类别，实际有10个完整案例），我发现coze-loop在提升可测试性方面，主要运用了以下几种模式：

4.1 依赖反转原则（DIP）

这是最重要的模式。coze-loop经常建议：

  • 定义接口或协议：明确依赖项应该提供什么能力
  • 依赖抽象，而非具体实现：业务逻辑只和接口对话
  • 具体实现通过依赖注入提供：在组合根（通常是依赖项函数）中组装

4.2 单一职责原则

每个依赖项函数只做一件事：

  • 要么创建对象
  • 要么配置对象
  • 要么管理对象生命周期

而不是所有事情混在一起。

4.3 显式优于隐式

coze-loop喜欢把隐藏的东西显式化：

  • 显式声明依赖参数
  • 显式管理配置
  • 显式处理副作用

这样测试时，你一眼就知道要Mock什么。

4.4 提供测试钩子

好的代码会考虑测试需求：

  • 提供可覆盖的默认值
  • 支持依赖替换
  • 暴露关键状态用于断言

5. 如何用coze-loop优化你自己的代码？

如果你也想用coze-loop提升代码可测试性，我的建议是：

  1. 先写测试，发现痛点：在写业务代码前，先想想“这个怎么测”。如果觉得难测试，可能就是设计有问题。

  2. 识别“测试异味”：

    • 函数内部new对象 → 提取为依赖
    • 到处读配置 → 集中管理
    • 依赖链太长 → 简化或提供短路机制
    • 隐藏的副作用 → 显式分离

  3. 用coze-loop验证优化方案：把你的“问题代码”贴进去，看看AI会怎么重构。即使不完全采用它的方案，也能给你很多启发。

  4. 渐进式重构：不要一次性重写所有代码。挑一个最痛的点，用coze-loop优化，写测试验证，没问题后再继续下一个。

6. 总结

FastAPI的依赖注入是个强大功能，但用不好反而会让测试变得困难。通过今天这10个案例，我们看到了如何通过一些简单的重构，大幅提升代码的可测试性。

关键收获：

  • 可测试的代码就是好代码：容易测试通常意味着关注点分离、接口清晰、耦合度低
  • 依赖注入不是银弹：要用对地方，遵循依赖反转原则
  • AI工具如coze-loop是很好的“第二双眼睛”：它能发现我们习以为常的坏味道，提供专业的重构建议

最后记住：写代码时多问一句“这个怎么测？”，很多设计问题就能提前避免。而当你遇到遗留代码时，不妨试试coze-loop，让它帮你找出那些隐藏的可测试性问题。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

# 单元测试
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

月之暗面 Kimi K3 正式开源！2.8万亿参数巨无霸，性能对标 GPT-5.6 / Claude 旗舰，免费下载！

avatar AI编程社区
cover

AI审计手记 #04：Claude Code源码拆解——记忆整理与多Agent协作的工程化启示

avatar AI编程社区
cover

Word Copilot 上新模型 Claude Opus 5

avatar AI编程社区