MQL5单元测试与TDD实战：EA质量保障的工程化方法

风险提示：本文为软件开发与技术服务类技术文章，仅用于MT5 EA程序化交易的技术研发交流与质量保障方法论探讨。文中涉及的单元测试方法、测试框架、Mock技术等均为软件工程原理演示，不构成任何投资建议、交易策略推荐或收益承诺。外汇、贵金属、CFD等杠杆交易存在极高风险，可能导致全部本金损失。读者应根据自身风险承受能力谨慎决策，并独立承担交易后果。

重点提示：单元测试的核心价值可以概括为三点：快速反馈——改完代码几秒钟就能知道有没有改坏；隔离验证——每个模块单独测试，出问题能准确定位；重构安全网——有测试保护，重构代码时不用担心破坏现有功能。

风险警示：单元测试不能替代回测和实盘验证。测试只能验证逻辑的正确性，无法验证策略的盈利能力。一个EA可以所有单元测试都通过，但策略本身可能就是亏钱的。单元测试和回测、实盘验证是互补关系，不是替代关系。

技术原理：为什么自建框架在MQL5中是可行的？因为单元测试框架的本质就是"一组断言函数 + 一个执行器"。断言函数负责检查条件并记录结果，执行器负责遍历所有测试用例并依次执行。这两个核心功能不依赖任何外部库，用纯MQL5语法就可以实现。相比之下，pytest、JUnit等框架之所以复杂，是因为它们支持参数化、fixture、插件系统等高级特性，而这些对于EA测试来说并不是必需的。

技术原理：断言宏的工作原理——通过宏将测试信息（文件名、行号、表达式）自动传入测试框架。我们写的ASSERT_EQ(a, b)看起来像一个函数，但实际上是一个宏。宏在预处理阶段展开时，会自动把__FILE__（当前文件名）和__LINE__（当前行号）一起传进去。这样当断言失败时，框架就能准确告诉你"哪个文件的第几行，哪个断言失败了"，大大提升了调试效率。如果用函数实现，就无法自动获取调用位置的信息。

风险警示：浮点比较陷阱——MQL5中double类型直接用==比较可能因精度问题导致测试误判，必须使用ASSERT_NEAR。这是新手写测试最容易踩的坑。比如你期望的结果是0.1，但实际计算的结果可能是0.1000000000000001或者0.0999999999999999，用==比较会失败，但从业务逻辑上来说它们应该是相等的。ASSERT_NEAR允许你指定一个误差范围（epsilon），只要两个值的差在这个范围内就算通过。

//+------------------------------------------------------------------+
//| CTestRunner 轻量单元测试框架 |
//| 功能：断言宏 + 测试用例注册 + 测试运行器 + 报告输出 |
//| 使用方法：包含此头文件，用TEST_CASE宏定义测试用例，OnInit中调用 |
//| CTestRunner::GetInstance().RunAll() 即可运行全部测试 |
//+------------------------------------------------------------------+

//--- 断言失败记录结构
struct SAssertFailure
{
string test_name; // 测试用例名称
string file_name; // 失败所在文件
int line_number; // 失败所在行号
string expression; // 失败的表达式
string expected; // 期望值（字符串形式）
string actual; // 实际值（字符串形式）
};

//--- 测试用例基类
class CTestCase
{
protected:
string m_name; // 测试用例名称
bool m_passed; // 是否通过
int m_failure_count; // 失败断言数量

public:
CTestCase(string name) : m_name(name), m_passed(true), m_failure_count(0) {}
virtual ~CTestCase() {}
string GetName() const { return m_name; }
bool IsPassed() const { return m_passed; }
int FailureCount() const { return m_failure_count; }
virtual void Run() = 0; // 子类实现具体测试逻辑

// 记录断言失败
void RecordFailure(string file, int line, string expr, string expected="", string actual="")
{
m_passed = false;
m_failure_count++;
Print(" [FAIL] ", file, ":", line, " - ", expr);
if(expected != "" || actual != "")
Print(" 期望: ", expected, " 实际: ", actual);
}
};

//--- 测试运行器（单例模式）
class CTestRunner
{
private:
static CTestRunner *m_instance;
CTestCase *m_cases[256]; // 测试用例数组（最多256个）
int m_case_count; // 已注册用例数
int m_passed_count; // 通过的用例数
int m_failed_count; // 失败的用例数

CTestRunner() : m_case_count(0), m_passed_count(0), m_failed_count(0) {}

public:
static CTestRunner* GetInstance()
{
if(m_instance == NULL)
m_instance = new CTestRunner();
return m_instance;
}

// 注册测试用例
void RegisterCase(CTestCase *test_case)
{
if(m_case_count < 256)
m_cases[m_case_count++] = test_case;
}

// 运行全部测试
void RunAll()
{
Print("========== 单元测试开始 ==========");
Print("总用例数: ", m_case_count);
Print("");

m_passed_count = 0;
m_failed_count = 0;

for(int i=0; i<m_case_count; i++)
{
Print("测试用例: ", m_cases[i].GetName());
m_cases[i].Run();
if(m_cases[i].IsPassed())
{
m_passed_count++;
Print(" [PASS] 通过");
}
else
{
m_failed_count++;
Print(" [FAIL] 失败，失败断言数: ", m_cases[i].FailureCount());
}
Print("");
}

Print("========== 测试结果汇总 ==========");
Print("总计: ", m_case_count, " 个用例");
Print("通过: ", m_passed_count, " 个");
Print("失败: ", m_failed_count, " 个");
if(m_failed_count == 0)
Print("🎉 全部测试通过！");
else
Print("⚠️ 有测试失败，请检查。");
Print("==================================");
}
};

CTestRunner* CTestRunner::m_instance = NULL;

//--- 断言宏定义
#define ASSERT_TRUE(cond) \
if(!(cond)) { RecordFailure(__FILE__, __LINE__, #cond); return; }

#define ASSERT_FALSE(cond) \
if(cond) { RecordFailure(__FILE__, __LINE__, "!(" #cond ")"); return; }

#define ASSERT_EQ(expected, actual) \
if((expected) != (actual)) { RecordFailure(__FILE__, __LINE__, #actual " == " #expected, DoubleToString(expected,8), DoubleToString(actual,8)); return; }

#define ASSERT_NEAR(expected, actual, epsilon) \
if(MathAbs((expected)-(actual)) > (epsilon)) { RecordFailure(__FILE__, __LINE__, #actual " ≈ " #expected, DoubleToString(expected,8), DoubleToString(actual,8)); return; }

//--- 测试用例注册宏
#define TEST_CASE(name) \
class CTest_##name : public CTestCase \
{ \
public: \
CTest_##name() : CTestCase(#name) { CTestRunner::GetInstance().RegisterCase(this); } \
virtual void Run(); \
}; \
static CTest_##name g_test_##name; \
void CTest_##name::Run()

//+------------------------------------------------------------------+
//| 使用示例：在OnInit中运行全部测试 |
//| |
//| int OnInit() |
//| { |
//| // 如果是测试模式，运行全部单元测试 |
//| #ifdef UNIT_TEST_MODE |
//| CTestRunner::GetInstance().RunAll(); |
//| return(INIT_SUCCEEDED); |
//| #endif |
//| // 正常EA初始化逻辑... |
//| return(INIT_SUCCEEDED); |
//| } |
//+------------------------------------------------------------------+

推荐实践：每个测试用例只测一件事。一个测试只验证一个行为，失败时能快速定位问题。如果你在一个测试用例里同时验证了均线计算、ATR计算、RSI计算，那么当这个测试失败时，你不知道是哪个计算出了问题，还得进一步排查。分开写，一个失败就知道对应的功能有bug。

推荐实践：测试用例命名要清晰，采用"函数名_场景_预期结果"的命名规范。比如CalcMaxLots_Balance1000_Return0_1、CalcMaxLots_Balance100000_ReturnMaxLots、CalcStopLoss_Fixed50Points_Return50。这样的命名方式，当测试失败时，看一眼用例名称就知道哪里出了问题，不用再去读测试代码。

//+------------------------------------------------------------------+
//| 风控函数单元测试示例 |
//| 被测函数：CalcMaxLots（最大仓位计算）、CalcStopLossDistance |
//| （止损距离计算）、CalcLotByRiskPercent |
//| （风险百分比换算手数） |
//+------------------------------------------------------------------+

//--- 测试1：最大仓位计算 - 正常资金
TEST_CASE(CalcMaxLots_NormalBalance_ReturnCorrectLot)
{
// Arrange: 准备测试数据
double balance = 1000.0; // 账户余额1000美元
double risk_percent = 2.0; // 风险比例2%
double stop_loss_points = 50; // 止损50点
double point_value = 10.0; // 每点价值10美元（标准手）
double max_lots = 5.0; // 最大手数限制
double min_lots = 0.01; // 最小手数

// Act: 调用被测函数
double result = CalcMaxLots(balance, risk_percent, stop_loss_points, point_value, max_lots, min_lots);

// Assert: 验证结果 - (1000*2%) / (50*10) = 20/500 = 0.04手
ASSERT_NEAR(0.04, result, 0.001);
}

//--- 测试2：最大仓位计算 - 大资金触发上限
TEST_CASE(CalcMaxLots_LargeBalance_ReturnMaxLots)
{
double balance = 1000000.0; // 100万美金
double risk_percent = 5.0; // 风险5%
double stop_loss_points = 20; // 止损20点
double point_value = 10.0;
double max_lots = 5.0; // 最大5手
double min_lots = 0.01;

double result = CalcMaxLots(balance, risk_percent, stop_loss_points, point_value, max_lots, min_lots);

// 计算值远大于max_lots，应该被限制在max_lots
ASSERT_EQ(max_lots, result);
}

//--- 测试3：最大仓位计算 - 极小资金取最小手数
TEST_CASE(CalcMaxLots_TinyBalance_ReturnMinLots)
{
double balance = 10.0; // 只有10美金
double risk_percent = 1.0; // 风险1% = 0.1美金
double stop_loss_points = 100; // 止损100点
double point_value = 10.0; // 每点10美金
double max_lots = 5.0;
double min_lots = 0.01; // 最小0.01手

double result = CalcMaxLots(balance, risk_percent, stop_loss_points, point_value, max_lots, min_lots);

// 计算值0.0001手小于最小手数，应返回min_lots
ASSERT_EQ(min_lots, result);
}

//--- 测试4：止损距离计算 - 固定点数模式
TEST_CASE(CalcStopLoss_FixedPoints_ReturnCorrectDistance)
{
double sl_points = 50.0;
double min_stop_level = 30; // 品种最小止损距离30点
int mode = 0; // 0=固定点数模式

double result = CalcStopLossDistance(sl_points, min_stop_level, mode);

ASSERT_EQ(50.0, result);
}

//--- 测试5：止损距离计算 - 小于最小止损距离时修正
TEST_CASE(CalcStopLoss_BelowMinLevel_ReturnMinLevel)
{
double sl_points = 20.0; // 设了20点止损
double min_stop_level = 30; // 品种要求至少30点
int mode = 0;

double result = CalcStopLossDistance(sl_points, min_stop_level, mode);

// 小于最小止损距离，应该被修正为最小止损距离
ASSERT_EQ(30.0, result);
}

//--- 测试6：止损距离计算 - ATR模式
TEST_CASE(CalcStopLoss_ATRMode_ReturnCorrectDistance)
{
double atr_value = 0.00500; // ATR值500点（如EURUSD）
double atr_multiplier = 1.5; // 1.5倍ATR止损
double min_stop_level = 30;
int mode = 2; // 2=ATR模式

double result = CalcStopLossDistance(atr_value, atr_multiplier, min_stop_level, mode);

// 500点 * 1.5 = 750点
ASSERT_NEAR(750.0, result, 0.1);
}

//--- 测试7：风险百分比换算手数 - 标准情况
TEST_CASE(CalcLotByRisk_NormalCase_ReturnCorrectLot)
{
double balance = 5000.0;
double risk_pct = 1.0; // 1%风险 = 50美金
double stop_loss_pips = 25; // 止损25点
double pip_value_per_lot = 10.0; // 每标准手每点10美金

double result = CalcLotByRiskPercent(balance, risk_pct, stop_loss_pips, pip_value_per_lot);

// 50 / (25 * 10) = 50 / 250 = 0.2手
ASSERT_NEAR(0.2, result, 0.001);
}

//--- 测试8：风险百分比换算手数 - 零风险
TEST_CASE(CalcLotByRisk_ZeroRisk_ReturnZero)
{
double balance = 5000.0;
double risk_pct = 0.0; // 0%风险
double stop_loss_pips = 25;
double pip_value_per_lot = 10.0;

double result = CalcLotByRiskPercent(balance, risk_pct, stop_loss_pips, pip_value_per_lot);

ASSERT_EQ(0.0, result);
}

进阶技巧：参数化测试——同一测试逻辑，多组输入数据批量执行，减少重复代码。比如上面的最大仓位计算测试，有3个不同的输入场景，但测试逻辑是一样的。可以把多组输入数据（balance, risk_percent, expected）放进一个数组，用循环批量执行断言。这样代码更简洁，添加新的测试数据也更方便。MQL5虽然没有内置的参数化测试支持，但用数组+循环很容易实现类似的效果。

技术原理：为什么需要Mock？因为MQL5的OrderSend、iClose等函数是平台内置的全局函数，无法直接替换。在单元测试中，你不希望真的发送订单（哪怕是模拟账户），也不希望测试依赖于当前的实时行情。如果直接调用这些全局函数，测试就变成了"集成测试"——既测试了你的代码，也测试了平台函数，而且结果还不稳定（因为行情一直在变）。单元测试的核心原则是"隔离"——只测你自己写的代码，外部依赖必须可控。

重点提示：Mock技术的核心思想是依赖注入 + 接口抽象，隔离外部依赖是单元测试的前提。你的EA交易模块不应该直接创建交易对象，而是通过构造函数参数或Set方法传入。这样在测试时，你就可以传入Mock对象而不是真实对象，实现测试和外部环境的完全隔离。

技术原理：依赖注入的实现方式——EA的交易模块不直接创建交易对象，而是通过参数传入，实现解耦。具体来说，你的策略类（比如CMyStrategy）有一个ITradingProvider类型的成员变量m_trading。策略类的构造函数接受一个ITradingProvider指针作为参数，把它保存到m_trading中。策略类的所有交易操作都通过m_trading->xxx()来调用，而不是直接调用OrderSend。这样，策略类本身不知道也不关心底层用的是真实交易还是Mock交易，它只依赖接口。这就是依赖注入——依赖的对象是被"注入"进来的，而不是自己创建的。

//+------------------------------------------------------------------+
//| Mock交易接口实现 |
//| 功能：通过接口抽象隔离真实交易函数，测试时使用Mock实现 |
//+------------------------------------------------------------------+

//--- 订单信息结构体（简化版）
struct SOrderInfo
{
ulong ticket; // 订单号
string symbol; // 交易品种
ENUM_ORDER_TYPE type; // 订单类型（买/卖）
double lots; // 手数
double open_price; // 开仓价
double sl; // 止损价
double tp; // 止盈价
datetime open_time; // 开仓时间
double profit; // 浮动盈亏
};

//--- 交易提供者接口
class ITradingProvider
{
public:
virtual ~ITradingProvider() {}

// 开仓：返回订单号，失败返回0
virtual ulong OpenPosition(string symbol, ENUM_ORDER_TYPE type, double lots,
double price, double sl, double tp, string comment="") = 0;

// 平仓：成功返回true
virtual bool ClosePosition(ulong ticket, double price=0.0) = 0;

// 修改止损止盈
virtual bool ModifyStopLoss(ulong ticket, double new_sl, double new_tp=0.0) = 0;

// 获取持仓数量
virtual int GetPositionCount() = 0;

// 获取持仓信息（按索引）
virtual bool GetPositionInfo(int index, SOrderInfo &info) = 0;

// 获取账户余额
virtual double GetBalance() = 0;
};

//--- Mock交易实现（用于单元测试）
class CTradingMock : public ITradingProvider
{
private:
SOrderInfo m_positions[128]; // 虚拟持仓列表
int m_position_count; // 当前持仓数
ulong m_next_ticket; // 下一个订单号
double m_balance; // 虚拟账户余额
double m_current_price; // 当前价格（用于计算浮盈）

public:
CTradingMock() : m_position_count(0), m_next_ticket(100001), m_balance(10000.0), m_current_price(1.10000) {}

// 设置初始余额
void SetBalance(double balance) { m_balance = balance; }

// 设置当前价格（用于模拟行情变动）
void SetCurrentPrice(double price) { m_current_price = price; UpdateFloatingPnL(); }

// 开仓
virtual ulong OpenPosition(string symbol, ENUM_ORDER_TYPE type, double lots,
double price, double sl, double tp, string comment="")
{
if(m_position_count >= 128) return 0; // 超过最大持仓数

SOrderInfo order;
order.ticket = m_next_ticket++;
order.symbol = symbol;
order.type = type;
order.lots = lots;
order.open_price = price;
order.sl = sl;
order.tp = tp;
order.open_time = TimeCurrent();
order.profit = 0.0;

m_positions[m_position_count++] = order;
return order.ticket;
}

// 平仓
virtual bool ClosePosition(ulong ticket, double price=0.0)
{
for(int i=0; i<m_position_count; i++)
{
if(m_positions[i].ticket == ticket)
{
// 计算平仓盈亏并更新余额（简化处理）
double close_price = (price > 0) ? price : m_current_price;
// ... 盈亏计算逻辑省略 ...

// 移除持仓（用最后一个元素覆盖）
m_positions[i] = m_positions[m_position_count - 1];
m_position_count--;
return true;
}
}
return false; // 未找到订单
}

// 修改止损止盈
virtual bool ModifyStopLoss(ulong ticket, double new_sl, double new_tp=0.0)
{
for(int i=0; i<m_position_count; i++)
{
if(m_positions[i].ticket == ticket)
{
m_positions[i].sl = new_sl;
if(new_tp > 0) m_positions[i].tp = new_tp;
return true;
}
}
return false;
}

// 获取持仓数量
virtual int GetPositionCount() { return m_position_count; }

// 获取持仓信息
virtual bool GetPositionInfo(int index, SOrderInfo &info)
{
if(index < 0 || index >= m_position_count) return false;
info = m_positions[index];
return true;
}

// 获取余额
virtual double GetBalance() { return m_balance; }

private:
// 更新浮动盈亏
void UpdateFloatingPnL()
{
for(int i=0; i<m_position_count; i++)
{
double diff = 0.0;
if(m_positions[i].type == ORDER_TYPE_BUY)
diff = m_current_price - m_positions[i].open_price;
else
diff = m_positions[i].open_price - m_current_price;
// 简化的盈亏计算（实际需要考虑点值等）
m_positions[i].profit = diff * m_positions[i].lots * 100000.0 / 10.0;
}
}
};

//+------------------------------------------------------------------+
//| 使用示例 |
//| |
//| // 策略类，依赖ITradingProvider接口 |
//| class CMyStrategy |
//| { |
//| private: |
//| ITradingProvider *m_trading; |
//| public: |
//| CMyStrategy(ITradingProvider *trading) : m_trading(trading) {} |
//| void OnTick() { /* 使用m_trading做交易操作 */ } |
//| }; |
//| |
//| // 测试时注入Mock |
//| TEST_CASE(Strategy_OpenOnSignal_ShouldOpenOnePosition) |
//| { |
//| CTradingMock *mock = new CTradingMock(); |
//| CMyStrategy strategy(mock); |
//| // ... 触发开仓信号 ... |
//| strategy.OnTick(); |
//| ASSERT_EQ(1, mock.GetPositionCount()); |
//| delete mock; |
//| } |
//+------------------------------------------------------------------+

进阶技巧：测试数据构造器（Builder模式）——快速构造复杂的行情/持仓测试数据。当你需要构造一个有5个持仓、每个持仓的参数都不同的测试场景时，手动一个个设置会很麻烦。可以写一个CStrategyTestBuilder类，提供流畅的API来快速构造测试场景，比如builder.WithBalance(5000).WithPosition("EURUSD", ORDER_TYPE_BUY, 0.1, 1.10000, 1.09500, 1.10500).Build()。这样测试代码的可读性会大大提高，构造复杂场景也变得轻松。

重点提示：TDD三阶段循环的核心原则：红→绿→重构，缺一不可。红（Red）——先写测试，测试肯定失败（因为功能还没实现），这是"红"；绿（Green）——写最少的代码让测试通过，代码可以不够优雅，先跑通再说，这是"绿"；重构（Refactor）——在测试保护下优化代码结构，提取函数，消除重复，每次重构后跑测试确保功能不变，这是"重构"。三个阶段构成一个循环，不断迭代推进。

推荐实践：修复bug时先写测试。每修复一个bug，就补充一个对应的测试用例，防止回归。具体做法是：先写一个能复现这个bug的测试用例（它应该是失败的），然后修复bug，测试通过。这样以后再有人改动相关代码时，如果这个bug又出现了，测试会立刻捕获到，不会等到实盘才发现。这是一个非常高效的质量提升手段——每修一个bug，你的测试集就强大一分。

# -*- coding: utf-8 -*-
# +------------------------------------------------------------------+
# | MQL5单元测试自动化运行脚本 |
# | 功能：自动编译EA → 运行测试 → 解析日志 → 生成JUnit报告 |
# | 使用场景：CI/CD流水线中的测试阶段 |
# +------------------------------------------------------------------+

import subprocess
import os
import re
import sys
from datetime import datetime

class MQL5TestRunner:
"""MQL5单元测试运行器"""

def __init__(self, metaeditor_path, ea_path, report_path):
self.metaeditor_path = metaeditor_path # MetaEditor路径
self.ea_path = ea_path # EA源码路径
self.report_path = report_path # 报告输出路径
self.test_cases = [] # 测试用例结果列表

def compile_ea(self):
"""编译EA源码"""
print("[1/4] 正在编译EA...")
# 调用MetaEditor命令行编译
# MetaEditor命令行编译参数: /compile:<文件> /log
cmd = [
self.metaeditor_path,
f"/compile:{self.ea_path}",
"/log"
]
result = subprocess.run(cmd, capture_output=True, text=True, timeout=60)

if result.returncode != 0:
print(f"编译失败！错误信息：{result.stdout}")
return False

# 检查编译结果日志中是否有error
if "0 error(s)" in result.stdout:
print("编译成功，0个错误")
return True
else:
print(f"编译存在错误：{result.stdout}")
return False

def run_tests(self):
"""运行单元测试（通过策略测试器执行）
实际项目中，这里可以通过调用terminal.exe
或策略测试器的命令行接口来运行测试模式的EA
"""
print("[2/4] 正在运行单元测试...")
# 注：以下为示例逻辑，实际使用时需要根据
# MetaTrader的命令行接口调整
# 核心思路：启动测试EA，EA在OnInit中运行所有测试并输出日志，
# 然后脚本读取日志文件解析结果

# 假设日志文件路径
log_file = os.path.join(os.path.dirname(self.ea_path), "Logs", "unit_test.log")

# （实际启动MT5运行测试EA的代码根据具体环境编写）
# 这里演示如何从日志中解析测试结果
if os.path.exists(log_file):
with open(log_file, 'r', encoding='utf-8') as f:
log_content = f.read()
self._parse_test_log(log_content)
return True
else:
print("警告：未找到测试日志文件，跳过测试解析")
return False

def _parse_test_log(self, log_content):
"""解析测试日志，提取用例结果"""
# 匹配测试用例名称和结果的正则表达式
# 日志格式示例：
# 测试用例: CalcMaxLots_NormalBalance_ReturnCorrectLot
# [PASS] 通过
# 或：
# 测试用例: CalcMaxLots_LargeBalance_ReturnMaxLots
# [FAIL] 失败，失败断言数: 2
# [FAIL] Test.mq5:123 - max_lots == result
test_case_pattern = r'测试用例:\s*(.+?)\n\s*\[(\w+)\]'
matches = re.findall(test_case_pattern, log_content)

for name, status in matches:
passed = (status == 'PASS')
self.test_cases.append({
'name': name.strip(),
'passed': passed,
'failure_message': '' if passed else '断言失败，请查看详细日志'
})

print(f"解析完成，共 {len(self.test_cases)} 个测试用例")

def generate_junit_report(self):
"""生成JUnit格式的XML测试报告，供CI平台展示"""
print("[3/4] 正在生成测试报告...")

total = len(self.test_cases)
failures = sum(1 for tc in self.test_cases if not tc['passed'])
timestamp = datetime.now().isoformat()

xml_lines = [
'<?xml version="1.0" encoding="UTF-8"?>',
f'<testsuites tests="{total}" failures="{failures}" timestamp="{timestamp}">',
f' <testsuite name="MQL5_Unit_Tests" tests="{total}" failures="{failures}">'
]

for tc in self.test_cases:
name = tc['name']
if tc['passed']:
xml_lines.append(f' <testcase name="{name}"/>')
else:
msg = tc['failure_message']
xml_lines.append(f' <testcase name="{name}">')
xml_lines.append(f' <failure message="{msg}"></failure>')
xml_lines.append(f' </testcase>')

xml_lines.append(' </testsuite>')
xml_lines.append('</testsuites>')

with open(self.report_path, 'w', encoding='utf-8') as f:
f.write('\n'.join(xml_lines))

print(f"测试报告已生成：{self.report_path}")
return True

def run(self):
"""运行完整测试流程"""
print("========== MQL5 单元测试 CI 任务 ==========")

# 步骤1：编译
if not self.compile_ea():
print("[4/4] 结果：编译失败，终止流程")
return 1

# 步骤2：运行测试
self.run_tests()

# 步骤3：生成报告
self.generate_junit_report()

# 步骤4：判定结果
failures = sum(1 for tc in self.test_cases if not tc['passed'])
print("[4/4] 测试执行完毕")
print(f" 总用例数: {len(self.test_cases)}")
print(f" 通过: {len(self.test_cases) - failures}")
print(f" 失败: {failures}")

if failures > 0:
print("❌ 存在测试失败，阻断CI流水线！")
return 1 # 非零退出码：失败
else:
print("✅ 全部测试通过！")
return 0 # 零退出码：成功

if __name__ == "__main__":
runner = MQL5TestRunner(
metaeditor_path=r"C:\Program Files\MetaTrader 5\metaeditor64.exe",
ea_path=r"C:\MQL5\Experts\MyEA\MyEA.mq5",
report_path=r"C:\CI\reports\test_results.xml"
)
sys.exit(runner.run())

进阶技巧：覆盖率评估实用方法——通过日志插桩 + Python脚本分析，估算MQL5代码的测试覆盖率。具体做法是：在每个函数的入口处加一行日志（可以用宏批量插入），记录"函数X被调用了"。运行完所有测试后，用Python脚本分析日志，统计哪些函数被调用过、哪些没有，从而得出函数级别的覆盖率。虽然不如行覆盖精确，但对于评估测试的整体覆盖程度已经足够了。更进一步，你可以在每个分支（if/else/case）里也加插桩日志，得到分支级别的覆盖率。

风险警示：测试代码本身也可能有bug。测试通过不代表功能正确，要警惕"假阳性"测试。比如断言写错了——期望的值写错了，刚好和错误的输出一致，测试就"假通过"了。或者断言的条件太宽松，比如ASSERT_NEAR的epsilon设得太大，任何差异都能通过。写测试时也要审查测试代码本身的正确性，重要的测试用例可以做"故障注入"——故意把被测代码改错，看测试能不能发现，如果改了还通过，说明测试有问题。

重点提示：测试金字塔原则：单元测试数量最多、集成测试次之、端到端测试最少。根据Google测试博客和Martin Fowler的经典文章《Test Pyramid》，一个合理的测试结构中，单元测试、集成测试、端到端测试的比例大约是7:2:1。原因很简单：单元测试运行快、成本低、定位准，所以应该多写；端到端测试运行慢、成本高、定位难，所以应该少写，只覆盖最核心的业务流程。

风险提示：本文为软件开发与技术服务类技术文章，仅用于MT5 EA程序化交易的技术研发交流与质量保障方法论探讨。文中涉及的单元测试方法、测试框架、Mock技术、CI/CD集成等均为软件工程原理演示，不构成任何投资建议、交易策略推荐或收益承诺。外汇、贵金属、CFD等杠杆交易存在极高风险，可能导致全部本金损失。单元测试只能验证代码逻辑的正确性，无法验证策略的盈利能力，策略有效性需要通过严格的回测和实盘验证。本文提到的任何技术方案均不对交易结果负责，读者应独立判断并自行承担全部风险。

第三方免责声明：本文中提及的任何第三方软件、工具、平台（包括但不限于MT5、MQL5、MetaTrader、MetaEditor、JUnit、Jenkins、GitHub Actions等）均为客观技术介绍，不代表本站对其进行推荐或担保。文中涉及的数据、案例、参数等信息仅供技术研究参考，实际使用效果因市场环境、账户配置、操作方式等因素而异。本站为软件开发与技术服务类网站，所有内容均围绕EA定制开发、技术咨询与教育服务展开，不从事任何代客理财、喊单带单或资金托管业务。