Databricks Repo运行pytest无法输出junitxml报告文件问题

问题对应结论 #

1. 现有运行配置确实存在遗漏 #

当前pytest.main参数无语法错误，但缺少四个关键配置校验与参数补全：

• 参数使用错误：-k mycode_test是按测试用例名、测试函数名做模糊匹配，并非按测试文件名匹配，要运行指定测试文件需直接将文件路径作为位置参数传入，否则pytest从Notebook默认工作目录递归扫描测试项时，文件写入的路径解析会出现偏差。
• 工作目录未校验：Databricks Repos中打开的Notebook，默认运行工作目录为集群节点本地临时路径，并非Repos文件实际存储路径，运行pytest前需通过import os; print(os.getcwd())确认当前工作目录，手动切换到测试文件所在目录。
• 输出捕获未关闭：需追加-s参数关闭pytest的默认输出捕获机制，否则文件写入阶段的报错日志会被pytest拦截，无法在Notebook单元格输出中展示。注意pytest的进程返回码仅反映测试用例的通过/失败状态，附属文件写入失败不会触发进程级异常，也不会改变返回码。
• 路径权限未校验：运行pytest前需先执行两段校验代码，确认目标路径可写：

  # 校验DBFS API层可访问
  dbutils.fs.ls("dbfs:/FileStore/")
  # 校验本地FUSE挂载路径可写
  import os
  os.path.exists("/dbfs/FileStore/")
  

2. 无法直接判定文件生成在未知路径 #

无异常抛出不代表文件写入成功，pytest对IO类非阻断错误仅打日志不终止进程。可在pytest运行完成后，同会话内执行以下代码全盘查找目标文件：

import os
for root, dirs, files in os.walk("/"):
    if "pytestreport.xml" in files:
        print(os.path.join(root, "pytestreport.xml"))

绝大多数场景下文件并未生成，核心原因是写入权限不足或文件系统操作不兼容，错误日志被pytest输出捕获机制隐藏。

3. 问题与DBFS FUSE挂载机制直接相关，但并非挂载故障 #

Databricks 10.4 LTS标准运行时的/dbfs FUSE挂载存在两个已知特性，会导致pytest文件写入静默失败：

• 权限限制：/dbfs FUSE挂载仅在集群driver节点生效，默认仅admin角色拥有写入权限，普通用户写入会直接返回权限拒绝错误。
• 操作支持限制：/dbfs FUSE挂载不支持文件原子重命名操作，pytest生成缓存文件、junitxml报告时，会先写入临时文件再通过原子重命名生成最终目标文件，该操作在FUSE挂载点会直接失败，无明确报错。
  可通过手动写入测试验证FUSE层问题：

with open("/dbfs/FileStore/test_write.txt", "w") as f:
    f.write("test")
print(dbutils.fs.ls("dbfs:/FileStore/test_write.txt"))

若该代码执行失败，即可确认是FUSE层权限或兼容性问题。

可直接复用的稳定运行方案 #

不要直接将pytest输出路径指向/dbfs FUSE挂载点，先写入集群本地临时目录，再通过Databricks工具类拷贝到DBFS，可绕过所有FUSE层兼容问题：

import os
import pytest

# 切换到测试文件所在的Repos目录，路径可从Repos文件详情页复制
os.chdir("/Workspace/Repos/对应仓库路径/")
# 创建本地临时缓存目录
local_cache_path = "/tmp/pytest_cache/"
local_report_path = "/tmp/pytestreport.xml"
os.makedirs(local_cache_path, exist_ok=True)

retcode = pytest.main([
    "./mycode_test.py",  # 直接指定测试文件，替代-k模糊匹配
    "-o", f"cache_dir={local_cache_path}",
    "--junitxml", local_report_path,
    "-v",
    "-s"
])

# 将本地生成的报告拷贝到DBFS
dbutils.fs.cp(f"file:{local_report_path}", "dbfs:/FileStore/pytestreport.xml")

内容的提问来源于stack exchange，提问作者bramb