tick-stock-panel测试体系拆解260测试用例背后的测试矩阵设计思路【免费下载链接】tick-stock-panelTSP自托管、零运维的 A 股「选股 监控 回测」量化工作台 | LLM能力驱使策略定制个股分析复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源项目地址: https://gitcode.com/GitHub_Trending/ti/tick-stock-paneltick-stock-panel 是一个自托管、零运维的 A 股「选股 监控 回测」量化工作台。对量化工具来说最危险的不是程序报错而是算错了却不报错——回测多算了一天的未来数据收益曲线就会好看得不合理。tick-stock-panel 的测试体系正是冲着这个痛点设计的backend/tests/下有240 个 pytest 测试文件其中回测子矩阵 29 个加上前端的 15 个单元测试文件共同构成一张覆盖数据契约 → 计算引擎 → API 行为三层边界的测试矩阵。测试矩阵总览目录即分层这套测试矩阵最直观的设计思路是测试目录结构镜像业务模块结构。你不需要读代码扫一眼文件名就知道每个子系统有哪些防线测试层位置职责典型测试文件回测引擎层tests/backtest/撮合正确性、防未来函数、优化器test_strategy_backtest_correctness.py数据契约层tests/ 顶层时区、单位、原子写入test_minute_timezone_contract.py因子/挖掘层顶层 backtestDSL、归因、并行挖掘test_factor_dsl.pyAPI 行为层顶层端点边界、缓存、限流test_alerts_query_bounds.py前端层frontend/src/格式化、组件、页面format.test.ts配置同样精简pytest 采用asyncio_mode auto见 pyproject.tomlasync 测试无需逐个加装饰器开发工具链由 dev extra 一键装齐pytest ruff mypy见 pyproject.toml。回测层合成行情 桩替身把未来函数挡在测试里回测引擎是量化系统的心脏它的测试文件 test_strategy_backtest_correctness.py 有 690 多行核心思路有两个。一是合成行情代替真实行情。测试用一个_synthetic_panel()函数构造前 50 天横盘 后 50 天上涨的确定性数据固定随机种子 42专门制造均线金叉信号。真实行情不可复现、还受网络影响合成数据则让哪一天该买入有唯一答案——引擎一旦在信号日之前看到未来的 K 线断言立刻失败。二是桩替身Stub隔离数据加载。测试里定义了_EngineStub、_RepoStub等替身类把从磁盘读数据这一环整体替换掉只留下撮合与信号逻辑被测。这样测试跑得飞快而且验证的永远是业务结果而非 I/O。叠加策略的端到端测试 test_composite_backtest_e2e.py 则走另一条路线用真实的内置子策略ma_golden_cross macd_golden完整跑通StrategyBacktestService.run()的 composite 分支覆盖 position/full 两种持仓模式与 union/intersect 两种信号合并模式——这正是2×2 参数矩阵的具象化。数据契约层时区、单位、原子写入——金融数据的第一性原则金融数据错误经常不报异常只产出看似合理的错误结果。tick-stock-panel 的规范文件 CONTRIBUTING.md 明确要求涉及关键字段时必须在变量名、边界转换或测试中证明口径正确。测试体系把这类规则变成了可执行的守卫时区契约test_minute_timezone_contract.py 守护分钟 K 的 datetime 必须是北京墙钟 naive这一契约覆盖 UTC 自愈 8 小时、tz-aware 换算、以及违规时fail-closed 拒收宁可拒收也不容忍错口径数据入库。并发死锁回归test_polars_guard.py 用多线程真实并发验证 polars 的 collect 并发闸——总闸限流、后台车道占满时交互请求仍能用上页面不会被后台计算饿死。原子写入test_atomic_parquet_writes.py 与 test_atomic_write_retry.py 保证 Parquet 分区在崩溃时不会出现写一半的脏文件。跨边界单位test_custom_pct_units.py这类测试专防百分比 ×100错误——规范明确禁止数值小于 1 就乘 100的启发式转换。因子挖掘层从 DSL 到并行作业的完整链路因子挖掘是 tick-stock-panel 的进阶能力见 docs/mining.md它的测试同样按链路分层DSL 层test_factor_dsl.py 验证因子表达式的解析与求值语义归因层test_factor_attribution.py 与 test_factor_metrics.py 确保因子收益归因口径正确运行层test_mining_runtime.py、test_mining_jobs.py 和 test_mining_process_lock.py 覆盖并行挖掘的作业调度、进程锁与超时取消配合 test_job_stall_and_cancel.py 处理作业卡死这类生产级故障场景。API 与实时层边界、并发与推送最外层测试验证用户真正接触到的行为几个设计细节值得借鉴边界先行test_alerts_query_bounds.py 专门压查询边界test_screener_run_all_as_of.py 用as of 某日的方式冻结时间验证选股结果可复现。缓存与并发写test_preferences_concurrent_write.py 模拟多人同时改偏好设置防止配置互相覆盖test_endpoint_latency_cold_cache.py 盯住冷缓存下的接口延迟。推送链路test_notification_adapters.py 用适配器模式测试飞书/企微等推送渠道飞书推送效果可见 推送飞书-自动复盘 对应的功能界面。故障隔离test_intraday_burst_fault_isolation.py 验证数据源突发异常不会拖垮整个服务——这是 CONTRIBUTING.md 中插件加载失败、字段缺失和空数据必须有隔离测试的落地。前端与工程规范15 个测试文件的克制和一份硬约束前端测试只有 15 个文件但选得很准纯函数format.test.ts、listNav.test.ts、图表组件EChartsCandlestick.test.tsx、关键页面Indices.test.tsx——不追求覆盖率数字只锁住最容易回归的地方。真正的矩阵约束写在 CONTRIBUTING.md 的 PR 清单里它规定了一张按改动类型分流的测试矩阵改动类型必须执行的测试后端纯函数 / bug 修复对应定向 pytest包含复现用例和边界用例API 契约service 测试 API 测试检查成功、无数据和错误三种响应数据源或插件provider 契约测试 缺能力 空数据 字段单位标准化缓存或性能命中/失效测试 并发快照测试前后端契约同时变化后端定向测试 前端构建 页面联调配合两条铁律——修复 bug 时优先编写能复现问题的测试再修到测试通过以及测试必须断言业务结果不能只断言接口返回 200——260 个用例不是堆数量而是每个用例都锚定一条明确的业务契约。日常运行也很轻uv run pytest tests/path/to/test_x.py -q即可定向回归。小结这张测试矩阵教会我们什么拆解完 tick-stock-panel 的测试体系可以提炼出三条对新手也实用的设计原则用合成数据制造有唯一正确答案的场景量化逻辑的可验证性立刻提升一个量级把口径写成契约把契约写成守卫测试时区、单位、fail-closed金融数据的错误大多静默守卫要替用户兜底测试目录镜像模块结构 按改动类型分流的测试矩阵让改哪里、测哪里成为肌肉记忆而不是靠运气。想深入参与建议从 CONTRIBUTING.md 和 AGENTS.md 读起再挑 tests/backtest/ 里一个测试文件对照源码看是理解这套体系最快的路径。【免费下载链接】tick-stock-panelTSP自托管、零运维的 A 股「选股 监控 回测」量化工作台 | LLM能力驱使策略定制个股分析复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源项目地址: https://gitcode.com/GitHub_Trending/ti/tick-stock-panel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考