litellm 无密钥单元测试体系tests/test_litellm 目录结构与运行指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmtests/test_litellm 是开源 LLM 网关项目 litellm 面向litellm/主包的一层1:1 镜像式单元测试目录其铁律是只允许纯 mock 测试——任何用例都不得依赖真实的 LLM API Key。本文围绕该目录的设计初衷、命名映射约定、隔离机制与运行方式展开读者可据此为 litellm 主包的任意模块快速补写可离线运行的测试并在本地以多进程方式一键执行。目录定位为何需要一套不联网的测试镜像litellm 主包位于 litellm/其代码横跨 100 家 LLM 提供商的适配层、路由算法、缓存、日志回调与 Proxy 管理端点。若每一处改动都要真连 Bedrock/Azure/OpenAI 才能验证贡献门槛与 CI 成本都会高得不可接受。readme.md 开宗明义地交代了这套目录的两个目标提升litellm/主包的测试覆盖率——用一套可离线执行的用例逼近每行生产代码都被单元测试触及降低贡献者补测试的门槛——不持有任何云厂商 API Key克隆仓库即可本地运行全部用例。基于这两点目录被约束为两点设计结构上 1:1 映射litellm/内容上只允许 mocked tests。也就是说在 tests/test_litellm 里不允许出现需要真实网络、真实密钥或真实外部服务的集成式断言。目录结构与 litellm/ 逐目录镜像对照 litellm/ 与 tests/test_litellm 的顶层结构可以直观看到一一对应的关系litellm/ 主包目录tests/test_litellm 测试镜像目录litellm/llms/100 提供商适配层tests/test_litellm/llms/litellm/caching/各类缓存实现tests/test_litellm/caching/litellm/proxy/Proxy 服务器与端点tests/test_litellm/proxy/litellm/router.pytests/test_litellm/test_router.pylitellm/main.pytests/test_litellm/test_main.pylitellm/compression/tests/test_litellm/compression/litellm/router_strategy/tests/test_litellm/router_strategy/litellm/router_utils/tests/test_litellm/router_utils/litellm/types/tests/test_litellm/types/litellm/secret_managers/、litellm/vector_stores/、litellm/responses/等同名镜像子目录除了与生产包对应的镜像目录目录根部还散落着一批模块级测试文件test_utils.py、test_router.py、test_logging.py、test_redis.py、test_secret_redaction.py等它们同样遵循下述命名规则映射到litellm/根部的同名模块。此外expected_fine_tuning_api/、expected_responses_api_request/、fixtures/等则存放断言用的期望数据与夹具属于非 1:1 的辅助目录。命名约定test_ .py 反查被测模块readme.md 给出了两条等价表述的映射规则是理解整套目录的索引litellm/proxy/caching_routes.py ←→ tests/test_litellm/proxy/test_caching_routes.py litellm/filename.py ←→ tests/test_litellm/test_filename.py也就是说文件名前加test_前缀、路径逐级平移即可定位被测对象。反向检索同样成立看到 tests/test_litellm/caching/test_disk_cache.py就能确定它测的是 litellm/caching/disk_cache.py看到 tests/test_litellm/proxy/test_caching_routes.py即可反查 litellm/proxy/caching_routes.py。例如 tests/test_litellm/test_router.py 覆盖 litellm/router.py 的 Router 类逻辑tests/test_litellm/test_main.py 覆盖 litellm/main.py 的completion/embedding等顶层 API。编写新用例时只需沿被测模块的路径镜像出同名测试文件即可无需关心该放哪一层的组织问题。纯 mock 测试约定测试风格与证据只允许 mock 测试意味着网络调用必须被替换。从仓库实际用例看主流手段有三种HTTP 层拦截respx / VCR大量提供商适配层测试通过 respx 拦截 outgoing 请求并回放固定响应例如tests/test_litellm/llms/compactifai/test_compactifai.py、tests/test_litellm/batches/test_batch_utils.py等仓库还提供_openai_record_replay_proxy.py与 VCR 相关的录制回放设施支撑这类用例。对象级 monkeypatchpytest-mockproxy/test_caching_routes.py 中通过mocker.patch.object(litellm, cache, mock_cache)用一个MagicMock伪造出带async_add_cache/ping的 Redis 缓存对象从而在无 Redis 实例的情况下驱动 FastAPITestClient完成/cache/delete等路由的断言。可选依赖守卫当被测特性依赖额外第三方库时使用pytest.importorskip如 caching/test_disk_cache.py 首行的pytest.importorskip(diskcache)缺库环境会自动跳过而不是让整套套件失败。值得注意mock不意味着简单。caching/test_disk_cache.py 对DiskCache.increment_cache的并发原子性做了一组非常严苛的测试用 8 个线程在threading.Barrier同步下同时自增断言最终结果精确等于初值加 8还分别验证了 key 缺失从零起步、叠加到既有整数、非整数缓存值视为零等边界。这些用例无需任何网络或密钥却把自增语义的并发正确性钉得很死——这正是纯 mock 单元测试能带来的深度。隔离机制conftest.py 如何保证测试互不污染litellm 是重度模块级全局状态callback 列表、缓存对象、Router 注册表、secret manager、logger handler的库若不加隔离测试之间的全局状态会互相泄漏。仓库在 tests/test_litellm/conftest.py 中构建了一套体系化的 autouse fixtureisolate_litellm_statefunction 作用域、autouse逐函数保存并清理 callback 全家族callbacks/success_callback/_async_success_callback等、路由全局量model_fallbacks、传输开关disable_aiohttp_transport/force_ipv4、缓存对象、secret manager 与模型成本映射用例结束后逐一还原同时清空内存缓存、失效get_model_info的 lru 缓存。isolate_host_aws_configautouse把 botocore 重定向到临时空目录并置空各类 AWS 环境变量防止开发者本机的~/.aws配置渗入 Bedrock 相关用例。isolate_host_os_keychainautouse置LITELLM_CLI_DISABLE_KEYRING1避免 CLI 密钥路径触碰真实操作系统钥匙串并提供FakeSecretVault内存替身模拟锁定/拒写/拒删/丢弃写入等密钥环异常态。setup_and_teardownmodule 作用域、autouse仅在单进程模式未检测到PYTEST_XDIST_WORKER下对litellm主模块做 reload并在注释中明确说明module reload parallel bad即并行运行时不重载避免竞态。conftest.py 顶部注释记录了这些设计决策的演进要点模块重载从 module 作用域收紧到 function 作用域、缓存冲刷改为逐函数执行、移除手工事件循环交由 pytest-asyncio 管理、加入 xdist worker 级隔离。这些都是仓库在并行化改造中沉淀下来的真实经验。运行方式Makefile 与 pytest 配置本地无需任何密钥即可执行。仓库通过 Makefile 暴露了分层入口例如第 44 行附近说明make test-unit即对应运行 tests/test_litellm而具体命令为Makefileuv run pytest tests/test_litellm -x -vv -n 4其中-n 4表示启用 pytest-xdist 4 进程并行。Makefile 还按主题切分了若干细分目标便于改动某个模块时只跑相关子集Makefilepytest tests/test_litellm/llms --tbshort -vv -n 4 --durations20—— 覆盖全部提供商适配层pytest tests/test_litellm/caching tests/test_litellm/responses ... -n 4—— 缓存、响应桥接、类型定义等pytest tests/test_litellm/test_*.py --tbshort -vv -n 4 --durations20—— 目录根部模块级测试。测试相关的统一配置位于 pyproject.toml 的[tool.pytest.ini_options]第 336 行起asyncio_mode auto使 async 测试无需显式pytest.mark.asyncioasyncio_default_fixture_loop_scope session定义事件循环复用策略同时注册了自定义 markerlimit_leaks内存泄漏检测阈值如 40 MB与no_parallel内存测量类用例须串行执行。日志方面过滤了 pydantic 序列化与 pytest-asyncio 弃用两类噪音告警保证 CI 输出干净。给贡献者的新测试撰写模板结合命名规则与现有用例风格为 litellm 新增一条纯 mock 单元测试的最小步骤可归纳为定位被测文件假设为litellm/caching/disk_cache.py则在tests/test_litellm/caching/下建立test_disk_cache.py若依赖未内置的三方库先pytest.importorskip守卫设计离线夹具用临时目录、MagicMock 或 respx 替换一切外部依赖如 Redis、HTTP 端点、AWS 凭据覆盖同步与 async 两种入口因为 pytest-asyncio 处于 auto 模式直接写async def test_...即可被自动收集执行利用 conftest 的自动隔离无需自己清理 callback/cache 全局量autouse fixture 会兜底。目录的1:1 镜像设计让加测试变成纯粹的机械映射这正是它面向贡献者友好的根本原因任何人给litellm/合并了新功能都能立刻找到对应镜像位补上离线用例。质量门禁与工程纪律这套目录不只是能跑还被纳入了仓库的工程纪律覆盖率断言tests/test_litellm/test_assert_ci_coverage.py 之类的自检测试会守护 CI 覆盖率水位突变测试pyproject.toml 的[tool.mutmut]配置将变异目标限定为litellm/proxy/management_endpoints/对应测试目录tests/test_litellm/proxy/management_endpoints/并注明变异覆盖线上已覆盖行才计分足见单元层用例被当作突变杀伤力的直接度量代码卫生目录根部还存在test_pre_commit_lint.py、test_type_discipline_gate.py、test_ruff_strict_gate.py等测试测试基建的元测试保证整个测试体系本身不被劣化。从这些机制可以推断tests/test_litellm承担的是 litellm 仓库中跑得快、无需密钥、可并行、可做突变度量的第一道防线与需要真实密钥的tests/llm_translation/、需要数据库与网络的tests/proxy_behavior/等层级做了清晰分工——主包逻辑的正确性论证尽量下沉到这一层完成越深的验证越依赖外部真环境。小结围绕 readme.md 展开可以看到它虽只有寥寥数行却定义了一整套可执行的工程约定目录 1:1 镜像、test_filename.py命名索引、纯 mock 铁律以及提升覆盖率 免密钥贡献的双重目标。结合 conftest.py 的隔离机制、Makefile 的并行执行入口与 pyproject.toml 的 pytest 全局配置任何开发者都能零成本地为这个连接 100 家 LLM 提供商的网关主包补上严谨、可离线、可持续运行的单元测试。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
litellm 无密钥单元测试体系：tests/test_litellm 目录结构与运行指南
litellm 无密钥单元测试体系tests/test_litellm 目录结构与运行指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmtests/test_litellm 是开源 LLM 网关项目 litellm 面向litellm/主包的一层1:1 镜像式单元测试目录其铁律是只允许纯 mock 测试——任何用例都不得依赖真实的 LLM API Key。本文围绕该目录的设计初衷、命名映射约定、隔离机制与运行方式展开读者可据此为 litellm 主包的任意模块快速补写可离线运行的测试并在本地以多进程方式一键执行。目录定位为何需要一套不联网的测试镜像litellm 主包位于 litellm/其代码横跨 100 家 LLM 提供商的适配层、路由算法、缓存、日志回调与 Proxy 管理端点。若每一处改动都要真连 Bedrock/Azure/OpenAI 才能验证贡献门槛与 CI 成本都会高得不可接受。readme.md 开宗明义地交代了这套目录的两个目标提升litellm/主包的测试覆盖率——用一套可离线执行的用例逼近每行生产代码都被单元测试触及降低贡献者补测试的门槛——不持有任何云厂商 API Key克隆仓库即可本地运行全部用例。基于这两点目录被约束为两点设计结构上 1:1 映射litellm/内容上只允许 mocked tests。也就是说在 tests/test_litellm 里不允许出现需要真实网络、真实密钥或真实外部服务的集成式断言。目录结构与 litellm/ 逐目录镜像对照 litellm/ 与 tests/test_litellm 的顶层结构可以直观看到一一对应的关系litellm/ 主包目录tests/test_litellm 测试镜像目录litellm/llms/100 提供商适配层tests/test_litellm/llms/litellm/caching/各类缓存实现tests/test_litellm/caching/litellm/proxy/Proxy 服务器与端点tests/test_litellm/proxy/litellm/router.pytests/test_litellm/test_router.pylitellm/main.pytests/test_litellm/test_main.pylitellm/compression/tests/test_litellm/compression/litellm/router_strategy/tests/test_litellm/router_strategy/litellm/router_utils/tests/test_litellm/router_utils/litellm/types/tests/test_litellm/types/litellm/secret_managers/、litellm/vector_stores/、litellm/responses/等同名镜像子目录除了与生产包对应的镜像目录目录根部还散落着一批模块级测试文件test_utils.py、test_router.py、test_logging.py、test_redis.py、test_secret_redaction.py等它们同样遵循下述命名规则映射到litellm/根部的同名模块。此外expected_fine_tuning_api/、expected_responses_api_request/、fixtures/等则存放断言用的期望数据与夹具属于非 1:1 的辅助目录。命名约定test_ .py 反查被测模块readme.md 给出了两条等价表述的映射规则是理解整套目录的索引litellm/proxy/caching_routes.py ←→ tests/test_litellm/proxy/test_caching_routes.py litellm/filename.py ←→ tests/test_litellm/test_filename.py也就是说文件名前加test_前缀、路径逐级平移即可定位被测对象。反向检索同样成立看到 tests/test_litellm/caching/test_disk_cache.py就能确定它测的是 litellm/caching/disk_cache.py看到 tests/test_litellm/proxy/test_caching_routes.py即可反查 litellm/proxy/caching_routes.py。例如 tests/test_litellm/test_router.py 覆盖 litellm/router.py 的 Router 类逻辑tests/test_litellm/test_main.py 覆盖 litellm/main.py 的completion/embedding等顶层 API。编写新用例时只需沿被测模块的路径镜像出同名测试文件即可无需关心该放哪一层的组织问题。纯 mock 测试约定测试风格与证据只允许 mock 测试意味着网络调用必须被替换。从仓库实际用例看主流手段有三种HTTP 层拦截respx / VCR大量提供商适配层测试通过 respx 拦截 outgoing 请求并回放固定响应例如tests/test_litellm/llms/compactifai/test_compactifai.py、tests/test_litellm/batches/test_batch_utils.py等仓库还提供_openai_record_replay_proxy.py与 VCR 相关的录制回放设施支撑这类用例。对象级 monkeypatchpytest-mockproxy/test_caching_routes.py 中通过mocker.patch.object(litellm, cache, mock_cache)用一个MagicMock伪造出带async_add_cache/ping的 Redis 缓存对象从而在无 Redis 实例的情况下驱动 FastAPITestClient完成/cache/delete等路由的断言。可选依赖守卫当被测特性依赖额外第三方库时使用pytest.importorskip如 caching/test_disk_cache.py 首行的pytest.importorskip(diskcache)缺库环境会自动跳过而不是让整套套件失败。值得注意mock不意味着简单。caching/test_disk_cache.py 对DiskCache.increment_cache的并发原子性做了一组非常严苛的测试用 8 个线程在threading.Barrier同步下同时自增断言最终结果精确等于初值加 8还分别验证了 key 缺失从零起步、叠加到既有整数、非整数缓存值视为零等边界。这些用例无需任何网络或密钥却把自增语义的并发正确性钉得很死——这正是纯 mock 单元测试能带来的深度。隔离机制conftest.py 如何保证测试互不污染litellm 是重度模块级全局状态callback 列表、缓存对象、Router 注册表、secret manager、logger handler的库若不加隔离测试之间的全局状态会互相泄漏。仓库在 tests/test_litellm/conftest.py 中构建了一套体系化的 autouse fixtureisolate_litellm_statefunction 作用域、autouse逐函数保存并清理 callback 全家族callbacks/success_callback/_async_success_callback等、路由全局量model_fallbacks、传输开关disable_aiohttp_transport/force_ipv4、缓存对象、secret manager 与模型成本映射用例结束后逐一还原同时清空内存缓存、失效get_model_info的 lru 缓存。isolate_host_aws_configautouse把 botocore 重定向到临时空目录并置空各类 AWS 环境变量防止开发者本机的~/.aws配置渗入 Bedrock 相关用例。isolate_host_os_keychainautouse置LITELLM_CLI_DISABLE_KEYRING1避免 CLI 密钥路径触碰真实操作系统钥匙串并提供FakeSecretVault内存替身模拟锁定/拒写/拒删/丢弃写入等密钥环异常态。setup_and_teardownmodule 作用域、autouse仅在单进程模式未检测到PYTEST_XDIST_WORKER下对litellm主模块做 reload并在注释中明确说明module reload parallel bad即并行运行时不重载避免竞态。conftest.py 顶部注释记录了这些设计决策的演进要点模块重载从 module 作用域收紧到 function 作用域、缓存冲刷改为逐函数执行、移除手工事件循环交由 pytest-asyncio 管理、加入 xdist worker 级隔离。这些都是仓库在并行化改造中沉淀下来的真实经验。运行方式Makefile 与 pytest 配置本地无需任何密钥即可执行。仓库通过 Makefile 暴露了分层入口例如第 44 行附近说明make test-unit即对应运行 tests/test_litellm而具体命令为Makefileuv run pytest tests/test_litellm -x -vv -n 4其中-n 4表示启用 pytest-xdist 4 进程并行。Makefile 还按主题切分了若干细分目标便于改动某个模块时只跑相关子集Makefilepytest tests/test_litellm/llms --tbshort -vv -n 4 --durations20—— 覆盖全部提供商适配层pytest tests/test_litellm/caching tests/test_litellm/responses ... -n 4—— 缓存、响应桥接、类型定义等pytest tests/test_litellm/test_*.py --tbshort -vv -n 4 --durations20—— 目录根部模块级测试。测试相关的统一配置位于 pyproject.toml 的[tool.pytest.ini_options]第 336 行起asyncio_mode auto使 async 测试无需显式pytest.mark.asyncioasyncio_default_fixture_loop_scope session定义事件循环复用策略同时注册了自定义 markerlimit_leaks内存泄漏检测阈值如 40 MB与no_parallel内存测量类用例须串行执行。日志方面过滤了 pydantic 序列化与 pytest-asyncio 弃用两类噪音告警保证 CI 输出干净。给贡献者的新测试撰写模板结合命名规则与现有用例风格为 litellm 新增一条纯 mock 单元测试的最小步骤可归纳为定位被测文件假设为litellm/caching/disk_cache.py则在tests/test_litellm/caching/下建立test_disk_cache.py若依赖未内置的三方库先pytest.importorskip守卫设计离线夹具用临时目录、MagicMock 或 respx 替换一切外部依赖如 Redis、HTTP 端点、AWS 凭据覆盖同步与 async 两种入口因为 pytest-asyncio 处于 auto 模式直接写async def test_...即可被自动收集执行利用 conftest 的自动隔离无需自己清理 callback/cache 全局量autouse fixture 会兜底。目录的1:1 镜像设计让加测试变成纯粹的机械映射这正是它面向贡献者友好的根本原因任何人给litellm/合并了新功能都能立刻找到对应镜像位补上离线用例。质量门禁与工程纪律这套目录不只是能跑还被纳入了仓库的工程纪律覆盖率断言tests/test_litellm/test_assert_ci_coverage.py 之类的自检测试会守护 CI 覆盖率水位突变测试pyproject.toml 的[tool.mutmut]配置将变异目标限定为litellm/proxy/management_endpoints/对应测试目录tests/test_litellm/proxy/management_endpoints/并注明变异覆盖线上已覆盖行才计分足见单元层用例被当作突变杀伤力的直接度量代码卫生目录根部还存在test_pre_commit_lint.py、test_type_discipline_gate.py、test_ruff_strict_gate.py等测试测试基建的元测试保证整个测试体系本身不被劣化。从这些机制可以推断tests/test_litellm承担的是 litellm 仓库中跑得快、无需密钥、可并行、可做突变度量的第一道防线与需要真实密钥的tests/llm_translation/、需要数据库与网络的tests/proxy_behavior/等层级做了清晰分工——主包逻辑的正确性论证尽量下沉到这一层完成越深的验证越依赖外部真环境。小结围绕 readme.md 展开可以看到它虽只有寥寥数行却定义了一整套可执行的工程约定目录 1:1 镜像、test_filename.py命名索引、纯 mock 铁律以及提升覆盖率 免密钥贡献的双重目标。结合 conftest.py 的隔离机制、Makefile 的并行执行入口与 pyproject.toml 的 pytest 全局配置任何开发者都能零成本地为这个连接 100 家 LLM 提供商的网关主包补上严谨、可离线、可持续运行的单元测试。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
