本文介绍通过依赖注入（而非全局或隐式导入）将测试中初始化的 spark 会话传递给被测模块，避免因模块内部硬编码 spark 初始化导致的测试失败和 mock 复杂性。
本文介绍通过依赖注入（而非全局或隐式导入）将测试中初始化的 spark 会话传递给被测模块，避免因模块内部硬编码 spark 初始化导致的测试失败和 mock 复杂性。
在 Pytest 中测试依赖 Spark 的函数时，一个常见痛点是：被测模块（如 file_to_be_tested.py）内部直接调用 SparkSession.builder... 或从其他模块导入并使用 Spark 实例，导致测试无法控制其行为——尤其当该模块中多个函数嵌套调用、且都隐式依赖同一 Spark 上下文时，单纯 patch 模块路径易出错、难维护，甚至引发会话冲突或资源泄漏。
推荐方案：显式依赖注入（Dependency Injection）
与其在模块内“偷偷”创建或导入 Spark 会话，不如将其作为参数显式传入，让模块职责更清晰、可测试性更强。这是 Python 中轻量但极其有效的设计实践。
✅ 方式一：函数级参数注入（简单直接）
修改 file_to_be_tested.py 中的 func1，接收 spark 作为显式参数：
# file_to_be_tested.py
def func1(df, spark_session):
# 原本可能写的：spark = SparkSession.builder.getOrCreate()
# 现在直接使用传入的会话
result_df = df.filter("age > 25")
return spark_session.sql("SELECT COUNT(*) FROM result_df") # 示例操作对应测试文件即可自然复用 pytest fixture 提供的 spark：
# test_file.py
import file_to_be_tested as t
def test_func(spark):
df = spark.read.json("test_data.json")
result = t.func1(df, spark) # 显式传入，无歧义
assert result.count() == 1✅ 方式二：类封装 + 构造注入（适合多函数共享会话）
若模块中多个函数共用 Spark 上下文，可封装为类，将 spark_session 在初始化时注入：
# file_to_be_tested.py
class SparkProcessor:
def __init__(self, spark_session):
self.spark = spark_session
def func1(self, df):
return self.spark.createDataFrame(df.toPandas()).filter("status = 'active'")
def func2(self, path):
return self.spark.read.parquet(path)测试时实例化即完成依赖绑定：
def test_func(spark):
processor = t.SparkProcessor(spark)
df = spark.range(10)
result = processor.func1(df)
assert result.count() == 10⚠️ 为什么不推荐 patch 或 monkeypatch？
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
立即学习“Python免费学习笔记（深入）”；
-
@patch('file_to_be_tested.SparkSession')需精准定位导入路径（常因from pyspark.sql import SparkSessionvsimport pyspark.sql而失败）； - 若
func1内部又调用了func2，而func2也新建 Spark 会话，则需 patch 多处，逻辑脆弱； - 隐式依赖掩盖真实协作关系，违反单一职责原则，长期维护成本高。
? 进阶提示
- 可结合 pytest fixture 将
SparkProcessor实例化为 fixture，实现跨测试复用； - 生产代码中，还可通过配置或工厂函数统一管理 Spark 会话生命周期（如
get_spark_session(mode="test")），进一步解耦环境差异。
总结：让依赖“可见”，比让依赖“可 mock”更重要。 一次重构，换来清晰的接口契约、稳定的单元测试与更易演化的代码结构。
