Elixir伞形项目中Mock库致mix test进程崩溃问题排查

可能原因及对应解决方案 #

1. Mock库与伞形项目的应用隔离冲突 #

伞形项目的各应用拥有独立运行环境，Mock库的全局钩子可能跨应用干扰进程生命周期，导致进程被意外终止。

• 解决：限定Mock作用域，在测试的setup/teardown中手动管理Mock进程，避免全局污染：

  setup do
    {:ok, mock_pid} = Mock.start_link([:global])
    on_exit(fn -> Mock.stop(mock_pid) end)
    :ok
  end
  
  test "list_syndicates/1 returns all known syndicates" do
    Mock.expect(File, :read!, fn _path -> "mock syndicate data" end)
    # 执行测试断言逻辑
  end
  

2. 原生File模块的模拟限制 #

File是Erlang原生模块，Mock库的字节码替换机制可能与Erlang VM的进程保护机制冲突，触发系统强制终止进程。

• 解决：改用官方推荐的Mox库，基于行为（Behaviour）实现模拟，避免直接修改原生模块：
  1. 定义行为模块：

     defmodule MyApp.FileBehaviour do
       @callback read!(path :: String.t()) :: String.t()
     end
     

  2. 业务代码依赖该行为：

     defmodule MyApp.Store.Reader do
       @behaviour MyApp.FileBehaviour
     
       @impl true
       def read!(path), do: File.read!(path)
     end
     

  3. 测试中用Mox模拟：

     Mox.defmock(MyApp.FileMock, for: MyApp.FileBehaviour)
     
     test "list_syndicates/1 returns all syndicates" do
       Mox.expect(MyApp.FileMock, :read!, fn _ -> "mock data" end)
       # 注入Mock并执行测试
     end
     

3. 测试进程资源耗尽 #

伞形项目批量执行测试时，Mock的额外开销可能触发系统的进程资源限制（如内存、CPU阈值），导致进程被杀死。

• 解决：
  • 单独运行故障测试文件，排查是否为单测试问题：mix test test/unit/store/reader_test.exs
  • 检查测试逻辑，避免无限循环、大体积数据生成等资源消耗操作
  • 调整Erlang VM参数，放宽资源限制：elixir --erl "+P 1000000 +MBas ageffcbf +MBcs 16384" mix test

4. 异步测试的并发冲突 #

若测试标记了async: true，多个进程同时Mock全局的File模块，会引发进程间状态冲突，导致进程异常终止。

• 解决：将故障测试设置为async: false，禁用并发：

  defmodule Manager.Impl.Store.ReaderTest do
    use ExUnit.Case, async: false
    # 测试代码
  end
  

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