Blender自动化测试实战：基于pytest与GitHub Actions的CI/CD方案

1. 项目概述：为什么Blender也需要自动化测试？

如果你和我一样，长期在Blender中进行三维创作、脚本开发或插件编写，一定经历过这样的场景：辛辛苦苦写了几百行Python脚本，为模型添加了复杂的骨骼绑定和动画逻辑，结果在Blender版本更新后，某个关键的API调用方式变了，或者自己修改了某个核心函数，导致整个工具链崩溃，却要花上几个小时去手动排查到底是哪一步出了问题。又或者，你开发了一个面向团队的内部插件，每次有同事提交新功能，你都得手动打开Blender，点一遍所有按钮，确保旧功能没被意外破坏——这种重复劳动既低效又容易出错。

这正是“Blender自动化测试”要解决的核心痛点。它不是一个锦上添花的功能，而是保障项目质量、提升开发效率、实现团队协作的基石。简单来说，自动化测试就是编写一系列脚本，模拟用户操作或验证代码逻辑，然后自动运行这些脚本来检查你的Blender项目（包括Python脚本、插件、材质节点组、几何节点等）是否按预期工作。

传统的Blender测试大多依赖“人肉测试”——手动打开软件，执行操作，用眼睛看结果。这种方法存在几个致命缺陷：不可重复（每次测试的路径和状态可能有细微差别）、效率低下（随着功能增多，测试时间线性增长）、容易遗漏（人总会疲劳和疏忽）。而自动化测试将测试用例代码化，可以一键运行成百上千个测试，快速给出通过或失败的报告，并能无缝集成到持续集成/持续部署（CI/CD）流程中，实现每次代码提交都自动验证。

本次实战指南，我将带你深入Blender自动化测试的核心，重点聚焦于如何利用成熟的Python测试框架pytest来构建健壮的测试套件，并最终将其配置到GitHub Actions这类CI/CD平台，实现真正的自动化测试流水线。无论你是独立开发者，还是团队中的技术负责人，这套方法都能显著提升你的Blender项目的可靠性和可维护性。

2. 核心工具链选型：为什么是pytest+CI/CD？

工欲善其事，必先利其器。为Blender搭建自动化测试体系，工具选型是关键第一步。市面上测试框架很多，我选择pytest作为核心，并推荐GitHub Actions作为CI/CD平台，是经过大量实践对比后的结果。

2.1 为什么选择pytest而不是unittest？

Python标准库自带了unittest框架，它当然也能用。但pytest在易用性、功能和社区生态上具有压倒性优势，尤其适合Blender测试这种场景。

• 更简洁的语法：pytest允许你用普通的Python函数和assert语句来写测试，无需继承任何类。写一个测试就像写一个普通函数一样自然。例如，测试一个Blender操作是否成功创建了对象，用pytest可能只需要三行代码，而unittest则需要更多的样板代码。
• 强大的Fixture机制：这是pytest的杀手锏。在Blender测试中，我们经常需要一些“测试夹具”，比如一个干净的、特定配置的Blender场景，或者一个加载了特定插件的Blender实例。Fixture可以让你以声明式的方式定义这些可重用的资源，并在测试函数中按需使用。你可以轻松地为一个测试类或模块设置“启动Blender并新建文件”的Fixture，避免每个测试都重复初始化。
• 丰富的插件生态：有大量插件可以扩展pytest功能。例如，pytest-xdist支持并行运行测试，能极大缩短大型测试套件的执行时间；pytest-cov可以生成测试覆盖率报告，帮你了解哪些代码没有被测试到。
• 更详细的失败信息：当断言失败时，pytest能智能地展示变量的值，帮助你快速定位问题，而unittest的输出通常比较简略。

对于Blender测试而言，我们经常需要与Blender的Python API (bpy) 交互，其状态管理（场景、对象、数据块）比较复杂。pytest的Fixture机制能优雅地管理这些状态的创建和清理，使测试代码更清晰、更健壮。

2.2 为什么选择GitHub Actions作为CI/CD平台？

CI/CD（持续集成/持续部署）的核心思想是：频繁地将代码集成到主干，并通过自动化流程进行构建和测试，以便快速发现错误。GitHub Actions是GitHub原生提供的CI/CD服务，它与代码仓库无缝集成，配置简单，功能强大，并且对于公开仓库有充足的免费额度。

• 零成本启动：如果你的项目托管在GitHub上，使用Actions几乎是零成本的。它直接运行在你的仓库中，无需额外申请服务器或配置复杂的Jenkins。
• 丰富的社区Action：有海量预构建的“Action”（可复用的任务步骤），例如“安装Python”、“缓存依赖”、“上传制品”等，可以像搭积木一样组合你的工作流。
• 完美的事件驱动：可以配置在push、pull_request等事件发生时自动触发测试，确保每次提交的代码都经过验证。
• 矩阵构建：可以轻松地针对多个Blender版本（如2.93 LTS, 3.0, 3.6, 最新版）运行测试，确保你的插件或脚本在不同版本下都能兼容。

将pytest测试套件与GitHub Actions结合，意味着你每次向GitHub推送代码，都会自动在一个纯净的虚拟环境中，针对指定的Blender版本运行所有测试。如果测试失败，你会立即收到通知，从而在错误合并到主分支前就将其修复。

注意：虽然本文以GitHub Actions为例，但核心的pytest测试方法是通用的。你可以类似地将其集成到GitLab CI、Jenkins、Azure Pipelines等其他CI/CD平台中。

3. 环境搭建与项目结构规划

在开始写测试之前，我们需要建立一个清晰、可维护的项目结构。一个混乱的目录结构会让测试难以管理和扩展。

3.1 推荐的项目目录结构

假设你的Blender插件或脚本项目名为my_blender_addon，我推荐如下结构：

my_blender_addon/ ├── src/ # 源代码目录 │ └── my_addon/ # 你的插件主目录 │ ├── __init__.py # Blender插件入口文件 │ ├── operators.py # 操作器（Operator）定义 │ ├── panels.py # 面板（Panel）定义 │ └── utils.py # 工具函数 ├── tests/ # 测试代码目录（核心！） │ ├── conftest.py # pytest配置文件，定义全局Fixture │ ├── test_operators.py # 针对operators.py的测试 │ ├── test_panels.py # 针对panels.py的测试 │ ├── test_utils.py # 针对utils.py的测试 │ └── assets/ # 测试用的资源文件（如.blend文件） │ └── test_scene.blend ├── .github/ │ └── workflows/ │ └── test.yml # GitHub Actions工作流定义文件 ├── requirements.txt # Python依赖列表（如pytest） ├── requirements-dev.txt # 开发环境额外依赖（如pytest-cov） ├── pyproject.toml # 现代Python项目配置（可选，但推荐） └── README.md

关键目录说明：

• src/: 存放你的生产代码。使用src布局是一种最佳实践，它能避免很多导入路径的混乱问题。
• tests/: 所有测试代码都放在这里，与源代码分离。conftest.py是pytest的本地配置文件，我们将在里面定义最重要的Fixture——用于启动和关闭Blender的“引擎”。
• .github/workflows/: 存放GitHub Actions的YAML配置文件。

3.2 创建虚拟环境与安装依赖

永远不要在系统Python环境下直接安装测试依赖。使用虚拟环境（venv, conda等）进行隔离。

# 在项目根目录下 python -m venv .venv # 激活虚拟环境 (Linux/macOS) source .venv/bin/activate # 激活虚拟环境 (Windows) .venv\Scripts\activate # 安装核心依赖：pytest pip install pytest # （可选）安装开发增强依赖 pip install pytest-xdist pytest-cov

将依赖记录到requirements.txt：

pytest>=7.0.0

3.3 编写第一个pytest Fixture：启动Blender

这是整个测试体系的核心。我们需要一个Fixture来启动一个“无头模式”（headless）的Blender实例。无头模式意味着Blender不启动图形界面，只运行Python解释器，这非常适合在服务器（如CI环境）上运行测试。

在tests/conftest.py中，我们定义这个核心Fixture：

import pytest import subprocess import sys import os from pathlib import Path def find_blender_executable(): """尝试在常见路径中查找Blender可执行文件。""" # 这里只是一个示例，你需要根据你的系统调整路径 possible_paths = [ # Windows Path("C:/Program Files/Blender Foundation/Blender 3.6/blender.exe"), # macOS Path("/Applications/Blender.app/Contents/MacOS/Blender"), # Linux Path("/usr/bin/blender"), Path.home() / "blender/blender", ] for path in possible_paths: if path.exists(): return str(path) # 如果找不到，可以尝试从环境变量读取 blender_env = os.environ.get("BLENDER_EXECUTABLE") if blender_env: return blender_env raise FileNotFoundError( "无法找到Blender可执行文件。请将其路径添加到环境变量BLENDER_EXECUTABLE中。" ) @pytest.fixture(scope="session") def blender_executable(): """返回Blender可执行文件的路径。""" return find_blender_executable() @pytest.fixture(scope="function") def run_blender_script(blender_executable, tmp_path): """ 一个Fixture，用于在Blender中运行一个Python脚本，并返回结果。 这个Fixture是函数级别的，每个测试函数都会运行一次。 """ def _runner(script_content, background=False): """ 参数: script_content (str): 要执行的Python代码字符串。 background (bool): 是否以后台模式运行（不加载用户配置）。 返回: subprocess.CompletedProcess: 包含stdout, stderr, returncode。 """ # 将脚本内容写入临时文件 script_file = tmp_path / "test_script.py" script_file.write_text(script_content) # 构建命令行参数 cmd = [blender_executable, "--background"] if background else [blender_executable] cmd.extend([ "--factory-startup", # 忽略用户配置，使用出厂默认设置 "--enable-autoexec", # 仍然允许运行Python脚本（与--factory-startup配合） "--python-exit-code", "1", # 如果Python脚本出错，Blender返回非零退出码 "--python", str(script_file) ]) # 运行Blender进程 result = subprocess.run( cmd, capture_output=True, # 捕获stdout和stderr text=True, cwd=tmp_path # 在临时目录中运行 ) return result return _runner

代码解析与注意事项：

1. find_blender_executable函数：这是一个辅助函数，用于定位系统上的Blender。在CI环境中（如GitHub Actions），我们通常会将Blender的安装路径通过环境变量BLENDER_EXECUTABLE传递，因此这里优先检查环境变量。
2. blender_executableFixture(scope="session")：这个Fixture在整个测试会话（即一次pytest命令执行过程）中只运行一次，并返回Blender的路径。scope="session"提高了效率。
3. run_blender_scriptFixture(scope="function")：这是最关键的Fixture。它接收一个Python脚本字符串，将其写入临时文件，然后启动Blender进程来执行这个脚本。
   • --background: 无头模式，不启动UI。
   • --factory-startup:极其重要！它确保Blender以纯净的默认配置启动，不加载你本地可能修改过的用户偏好设置、已安装的插件等。这保证了测试环境的一致性，是可靠自动化测试的基石。
   • --enable-autoexec: 与--factory-startup配合使用，允许执行Python脚本。
   • --python-exit-code 1: 告诉Blender，如果执行的Python脚本中有未捕获的异常，就以退出码1结束。这样我们就能通过进程的returncode来判断测试是否通过。
   • capture_output=True: 捕获Blender运行的所有输出（包括print语句和错误信息），便于我们调试。
   • tmp_path: pytest内置的Fixture，为每个测试函数提供一个唯一的临时目录，避免测试间文件干扰。

实操心得：在本地开发时，你可能会遇到因为已安装的插件冲突导致测试行为不一致的情况。始终坚持使用--factory-startup可以彻底避免这个问题，让你的本地测试与CI测试环境完全对齐。

4. 编写你的第一个Blender pytest测试

有了核心Fixture，我们现在可以开始编写真正的测试了。让我们从一个简单的工具函数测试开始。

假设在src/my_addon/utils.py中有一个函数，用于计算两个向量的点积（当然，Blender有内置的，这里仅作示例）：

# src/my_addon/utils.py def dot_product(v1, v2): """计算两个三维向量的点积。""" if len(v1) != 3 or len(v2) != 3: raise ValueError("Vectors must be 3-dimensional") return sum(a * b for a, b in zip(v1, v2))

对应的测试文件tests/test_utils.py可以这样写：

# tests/test_utils.py import sys import os # 将src目录添加到Python路径，以便导入我们的插件模块 sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..', 'src')) from my_addon.utils import dot_product def test_dot_product_basic(): """测试点积的基本功能。""" v1 = (1, 2, 3) v2 = (4, 5, 6) # 1*4 + 2*5 + 3*6 = 4 + 10 + 18 = 32 result = dot_product(v1, v2) assert result == 32 def test_dot_product_zero_vector(): """测试与零向量的点积。""" v1 = (0, 0, 0) v2 = (1, 2, 3) result = dot_product(v1, v2) assert result == 0 def test_dot_product_raises_error(): """测试输入非三维向量时是否抛出异常。""" v1 = (1, 2) # 二维向量 v2 = (3, 4, 5) try: dot_product(v1, v2) # 如果上面没抛出异常，测试失败 assert False, "Expected ValueError was not raised" except ValueError as e: # 检查异常信息是否符合预期 assert "3-dimensional" in str(e)

这是一个纯Python函数的单元测试，不涉及Blender API。运行它很简单：

pytest tests/test_utils.py -v

4.1 测试涉及Blender API的操作器（Operator）

真正的挑战在于测试那些会操作Blender数据（如创建物体、修改网格）的代码。假设我们有一个操作器，用于在场景中心创建一个立方体：

# src/my_addon/operators.py import bpy class MYADDON_OT_create_test_cube(bpy.types.Operator): bl_idname = "my_addon.create_test_cube" bl_label = "Create Test Cube" bl_options = {'REGISTER', 'UNDO'} def execute(self, context): # 清除场景中所有物体（仅用于测试，生产环境慎用） bpy.ops.object.select_all(action='SELECT') bpy.ops.object.delete(use_global=False) # 在原点创建立方体 bpy.ops.mesh.primitive_cube_add(size=2.0, location=(0, 0, 0)) new_cube = context.active_object new_cube.name = "TestCube" # 添加一个简单的材质（可选） mat = bpy.data.materials.new(name="TestMaterial") mat.diffuse_color = (1.0, 0.2, 0.2, 1.0) # 红色 new_cube.data.materials.append(mat) self.report({'INFO'}, f"Created cube: {new_cube.name}") return {'FINISHED'}

如何测试这个操作器？我们需要在Blender的上下文中运行它，并验证结果。在tests/test_operators.py中：

# tests/test_operators.py import sys import os sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..', 'src')) def test_create_test_cube_operator(run_blender_script): """测试创建立方体操作器。""" # 1. 准备要运行的Python脚本 test_script = """ import bpy import sys import os # 模拟插件的注册（在真实的测试中，这部分可能由conftest中的Fixture处理） # 这里我们简单地将插件目录添加到路径并导入 plugin_dir = r\"\"\"{plugin_dir}\"\"\" sys.path.insert(0, plugin_dir) try: import my_addon # 通常你需要在这里调用 my_addon.register()，但为了测试简单，我们直接导入操作器类 from my_addon.operators import MYADDON_OT_create_test_cube except ImportError as e: print(f\"ERROR: Failed to import addon: {e}\") sys.exit(1) # 确保场景是干净的（由--factory-startup保证，但再清理一次也无妨） if bpy.context.mode != 'OBJECT': bpy.ops.object.mode_set(mode='OBJECT') bpy.ops.object.select_all(action='SELECT') bpy.ops.object.delete() # 执行我们的操作器 try: bpy.ops.my_addon.create_test_cube() except Exception as e: print(f\"ERROR: Operator failed: {e}\") sys.exit(1) # 验证结果 cubes = [obj for obj in bpy.data.objects if obj.type == 'MESH' and obj.name.startswith('TestCube')] if len(cubes) != 1: print(f\"FAIL: Expected 1 cube named 'TestCube', found {{len(cubes)}}: {{[c.name for c in cubes]}}\") sys.exit(1) cube = cubes[0] if cube.location != (0.0, 0.0, 0.0): print(f\"FAIL: Cube location is {{cube.location}}, expected (0,0,0)\") sys.exit(1) if len(cube.data.materials) == 0: print(\"FAIL: Cube has no material assigned\") sys.exit(1) if cube.data.materials[0].name != \"TestMaterial\": print(f\"FAIL: Material name is {{cube.data.materials[0].name}}, expected 'TestMaterial'\") sys.exit(1) print(\"SUCCESS: Test cube created and validated successfully.\") sys.exit(0) # 明确返回成功 """.format(plugin_dir=os.path.join(os.path.dirname(__file__), '..', 'src').replace("\\", "\\\\")) # 2. 使用Fixture运行脚本 result = run_blender_script(test_script, background=True) # 3. 断言结果 # 检查进程退出码是否为0（成功） assert result.returncode == 0, f\"Blender script failed with exit code {{result.returncode}}.\\nSTDOUT:\\n{{result.stdout}}\\nSTDERR:\\n{{result.stderr}}\" # 检查输出中是否包含成功信息（可选，但有助于调试） assert \"SUCCESS\" in result.stdout

测试逻辑拆解：

1. 脚本内联：我们将整个测试逻辑写成一个多行字符串test_script。这个字符串中包含的Python代码，会在一个由run_blender_scriptFixture启动的、全新的Blender进程中执行。
2. 环境准备：脚本开头添加插件源码路径并导入模块。由于我们使用了--factory-startup，这个Blender实例里没有安装我们的插件，所以需要动态导入。
3. 执行操作：调用bpy.ops.my_addon.create_test_cube()来执行操作器。
4. 结果验证：通过查询bpy.data.objects和bpy.data.materials来验证立方体是否被正确创建、命名、定位和赋予材质。
5. 退出码控制：验证逻辑中，如果任何检查失败，我们使用sys.exit(1)让进程以非零码退出。如果全部通过，则sys.exit(0)。
6. 外部断言：在测试函数test_create_test_cube_operator中，我们通过run_blender_scriptFixture拿到子进程的结果对象result。核心断言是result.returncode == 0。如果非零，我们将标准输出和错误输出打印出来，极大方便了调试。

踩坑记录：最初我尝试在测试函数内部直接import bpy并操作，这是行不通的。因为pytest运行在你自己系统的Python环境中，而bpy模块只有在Blender的Python解释器内才可用。必须通过子进程启动Blender来运行测试脚本，这是Blender自动化测试架构的关键。

5. 构建健壮的测试套件：Fixture进阶与测试策略

单一的测试函数不够，我们需要一套可维护、可扩展的测试体系。

5.1 使用更高级的Fixture管理复杂场景

前面的run_blender_scriptFixture每次测试都启动一个全新的Blender进程，虽然干净，但对于多个需要相同初始状态的测试来说，可能较慢。我们可以创建更复杂的Fixture来复用状态。

例如，创建一个Fixture，它启动一个Blender，并预先注册好我们的插件：

# tests/conftest.py (追加) import tempfile import zipfile @pytest.fixture(scope="session") def blender_with_addon_installed(blender_executable, tmp_path_factory): """ 启动一个Blender会话，并已将我们的插件安装为一个zip文件。 这是一个会话级Fixture，所有测试共享同一个Blender实例（节省启动时间）。 注意：由于Blender的Python模块状态在会话中持续存在，测试之间必须小心清理数据。 """ # 创建一个临时目录用于构建插件zip addon_build_dir = tmp_path_factory.mktemp("addon_build") src_dir = Path(__file__).parent.parent / "src" / "my_addon" # 1. 将插件源码复制到构建目录（这里简化处理，实际可能需要处理所有文件） # 2. 创建一个__init__.py文件，其bl_info包含插件信息（如果src中的没有） # 3. 将整个目录打包成zip zip_path = addon_build_dir / "my_addon.zip" with zipfile.ZipFile(zip_path, 'w', zipfile.ZIP_DEFLATED) as zipf: for file_path in src_dir.rglob("*"): if file_path.is_file(): arcname = file_path.relative_to(src_dir.parent) # 保持目录结构 zipf.write(file_path, arcname) # 启动Blender并安装插件（通过Python脚本） install_script = f""" import bpy import sys import os zip_path = r\"\"\"{zip_path}\"\"\" # 安装插件 try: bpy.ops.preferences.addon_install(filepath=zip_path) # 启用插件 bpy.ops.preferences.addon_enable(module='my_addon') except Exception as e: print(f\"ERROR installing addon: {{e}}\") sys.exit(1) print(\"SUCCESS: Addon installed and enabled.\") # 保持在运行状态，供后续测试使用 # 注意：在实际测试中，我们可能需要通过进程间通信来向这个长期运行的Blender发送命令。 # 这更复杂，通常更简单的做法还是每个测试用独立的干净进程。 """ # 这里演示了安装，但长期运行交互式测试比较复杂。 # 更常见的模式是：每个测试函数启动一个干净的Blender进程，但通过缓存或预构建的.blend文件来加速初始化。 # 因此，对于大多数情况，run_blender_script（function级别）是更简单可靠的选择。 print(f"Addon zip created at: {zip_path}") # 返回一个可以与该Blender实例交互的“句柄”（这里简化，实际可能需要用socket或文件进行IPC） # 本例中，我们暂时不实现复杂的会话级交互，仍推荐使用function级Fixture。 yield None # 清理...

对于大多数项目，我建议保持测试的独立性。每个测试函数启动一个干净的Blender进程（使用--factory-startup），虽然稍微慢一点，但能保证绝对的隔离性，避免测试间的状态污染，结果更可靠。性能问题可以通过pytest-xdist并行运行测试来缓解。

5.2 测试分类与标记（Mark）

pytest允许你给测试打上标记（mark），以便有选择地运行。

# tests/test_operators.py import pytest @pytest.mark.slow def test_complex_geometry_processing(run_blender_script): """这是一个耗时很长的测试。""" # ... 复杂的几何节点或修改器测试 ... pass @pytest.mark.ui def test_panel_draw(run_blender_script): """测试UI面板是否能正确绘制（可能需要不同的启动参数）。""" # 注意：测试UI绘制通常需要非无头模式，这更适合本地开发，CI中可能跳过。 pass def test_fast_utility(): """这是一个快速的纯Python单元测试。""" # ... pass

然后，你可以这样运行测试：

# 运行所有测试 pytest # 只运行不慢的测试（排除标记为slow的） pytest -m "not slow" # 只运行快速测试 pytest -m "not slow and not ui" # 并行运行所有测试（使用pytest-xdist） pytest -n auto

5.3 使用参数化测试覆盖多种情况

pytest的@pytest.mark.parametrize装饰器可以让你用不同的参数多次运行同一个测试函数，非常适合测试边界值和多种输入。

# tests/test_utils.py import pytest @pytest.mark.parametrize("v1, v2, expected", [ ((1, 0, 0), (1, 0, 0), 1.0), # 同向 ((1, 0, 0), (-1, 0, 0), -1.0), # 反向 ((1, 0, 0), (0, 1, 0), 0.0), # 垂直 ((2, 3, 4), (5, 6, 7), 56), # 任意值 2*5+3*6+4*7=56 ]) def test_dot_product_parametrized(v1, v2, expected): from my_addon.utils import dot_product result = dot_product(v1, v2) assert result == expected

6. 集成CI/CD：使用GitHub Actions自动运行测试

现在，我们已经有了一个完整的pytest测试套件，可以在本地运行。下一步是让它自动化，每次代码推送都自动执行。我们将配置GitHub Actions。

在项目根目录创建.github/workflows/test.yml：

name: Blender Addon CI on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest # 也可以使用 windows-latest 或 macos-latest strategy: matrix: # 测试多个Blender版本，确保兼容性 blender-version: ['3.6.0', 'latest'] python-version: ['3.10'] # Blender 3.6+ 通常内置 Python 3.10 steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} - name: Install Python dependencies run: | python -m pip install --upgrade pip pip install pytest pytest-xdist - name: Download and install Blender ${{ matrix.blender-version }} run: | # 使用社区维护的Action来安装Blender，这是一个更可靠的方式 # 这里我们手动实现一个简单版本 BLENDER_VERSION=${{ matrix.blender-version }} if [ "$BLENDER_VERSION" = "latest" ]; then # 获取最新稳定版版本号（示例逻辑，实际可能需要解析HTML或API） BLENDER_VERSION="3.6.0" fi # 构建下载URL (Linux版本示例) # 注意：Blender官网的URL模式可能会变，需要根据实际情况调整 DOWNLOAD_URL="https://download.blender.org/release/Blender${BLENDER_VERSION%.*}/blender-${BLENDER_VERSION}-linux-x64.tar.xz" echo "Downloading Blender from: $DOWNLOAD_URL" wget -q $DOWNLOAD_URL -O blender.tar.xz tar -xf blender.tar.xz # 找到解压后的可执行文件路径 BLENDER_EXEC_PATH=$(find . -name "blender" -type f -executable | head -n 1) echo "Blender executable found at: $BLENDER_EXEC_PATH" # 将其路径添加到环境变量，供后续步骤使用 echo "BLENDER_EXECUTABLE=$PWD/${BLENDER_EXEC_PATH:2}" >> $GITHUB_ENV # 给予执行权限 chmod +x $BLENDER_EXEC_PATH - name: Run tests with pytest env: BLENDER_EXECUTABLE: ${{ env.BLENDER_EXECUTABLE }} run: | # 运行测试，并输出详细的报告 python -m pytest tests/ -v --tb=short # 如果你想生成覆盖率报告（需要pytest-cov） # python -m pytest tests/ -v --cov=src/my_addon --cov-report=xml - name: Upload test results (optional) if: always() # 即使测试失败也上传 uses: actions/upload-artifact@v4 with: name: test-results-${{ matrix.blender-version }} path: | test-results/ .coverage retention-days: 7

工作流解析：

1. 触发条件：当向main或develop分支推送代码，或向这些分支发起拉取请求时，工作流自动触发。
2. 矩阵策略：strategy.matrix允许我们并行运行多个作业。这里我们针对两个Blender版本（3.6.0和latest）进行测试。这能有效发现版本兼容性问题。
3. 安装Blender：这是最关键的一步。我们通过wget从Blender官网下载指定版本的Linux二进制包（示例中是Linux runner）。解压后，找到blender可执行文件，并将其绝对路径存入环境变量BLENDER_EXECUTABLE。我们的conftest.py中的find_blender_executable函数会读取这个环境变量。
4. 运行测试：使用pytest命令运行tests/目录下的所有测试。-v显示详细信息，--tb=short提供简短的错误回溯。
5. 上传制品：如果测试失败，我们可以将测试结果（如日志、覆盖率报告）上传为制品，方便下载查看。

重要提示：上述安装Blender的步骤是基础示例。在实际项目中，我强烈推荐使用社区维护的GitHub Action，例如actions/setup-blender（如果可用），或者自己编写一个更健壮的、支持多平台的安装脚本。因为Blender的下载URL和压缩包结构可能会变化。

6.1 优化：使用缓存加速

每次CI运行都下载Blender压缩包可能会浪费时间和带宽。我们可以使用GitHub Actions的缓存功能。

- name: Cache Blender installation uses: actions/cache@v4 id: cache-blender with: path: blender-${{ matrix.blender-version }} key: ${{ runner.os }}-blender-${{ matrix.blender-version }}-${{ hashFiles('.github/workflows/test.yml') }} restore-keys: | ${{ runner.os }}-blender-${{ matrix.blender-version }}- - name: Install Blender if: steps.cache-blender.outputs.cache-hit != 'true' run: | # ... 上述下载和解压Blender的代码 ... # 解压后，将目录重命名为固定的名字，以便缓存 mv blender-* blender-${{ matrix.blender-version }}

7. 常见问题、调试技巧与最佳实践

在搭建和运行Blender自动化测试的过程中，你肯定会遇到各种问题。这里记录了我踩过的一些坑和总结的技巧。

7.1 常见问题与解决方案

7.2 调试技巧

• 打印详细日志：在测试脚本中大量使用print()语句，输出关键变量的值、执行步骤等。这些输出会被run_blender_script捕获，并在测试失败时显示出来。
• 保存调试文件：在测试脚本中，如果遇到复杂的数据问题，可以将场景保存为.blend文件或导出为JSON等格式，供后续分析。

  # 在测试脚本中 debug_file = “/tmp/debug_scene.blend” bpy.ops.wm.save_as_mainfile(filepath=debug_file) print(f“Debug scene saved to: {debug_file}”)

• 使用pytest的-s和-v参数：在本地运行测试时，使用pytest -v -s可以禁止输出捕获，让你看到测试过程中所有的print输出，便于实时调试。
• 在CI中检查制品：如果测试在CI中失败，下载上传的制品（如日志），仔细查看stdout和stderr。

7.3 最佳实践总结

1. 隔离性至上：每个测试函数应尽可能独立，使用--factory-startup启动一个全新的Blender进程。虽然牺牲了一点速度，但换来了极高的可靠性。
2. 测试要快：尽量编写执行速度快的测试。复杂的集成测试可以标记为@pytest.mark.slow，并在日常开发中跳过。利用pytest-xdist进行并行测试。
3. 测试行为，而非实现：关注操作器的最终效果（如“场景中是否创建了名为‘Cube’的物体？”），而不是其内部实现细节（如“是否调用了bpy.ops.mesh.primitive_cube_add？”）。这样即使内部重构，测试也无需频繁修改。
4. 从简单的单元测试开始：先为你插件中的纯逻辑函数（不依赖bpy的）编写单元测试。这些测试运行飞快，能快速验证核心逻辑。
5. CI配置即代码：将你的CI/CD配置（如.github/workflows/test.yml）纳入版本控制。任何团队成员都可以看到测试是如何运行的，并且能复现CI环境。
6. 及时处理失败的测试：CI测试失败应被视为最高优先级的问题之一。它意味着主分支的代码可能处于不可用状态。养成习惯，在修复代码的同时，也更新或添加相应的测试。

将自动化测试融入Blender插件或脚本的开发流程，初期会花费一些时间搭建框架和编写测试用例，但从长远来看，它节省的是无数个小时的手动回归测试时间，并极大地增强了你对代码修改的信心。当你的测试套件在每次提交时自动运行，并给出清晰的红绿信号时，你会发现，开发Blender扩展也可以像开发其他软件一样，具备现代、高效的工程实践。