定时选股先怎么试跑：检查触发时间、失败分支和重复执行
依赖定时选股之前，要试跑它什么时候执行、实际调用哪些步骤、正常和失败时发布什么。最终文字说“已更新”不足以作为证据。把触发时刻与供应商载荷固定下来回放，用预先写好的调用顺序、逻辑时段和输出数量核对实际行为。交付是一份能重复执行的测试记录，不是对生成回答风格的主观打分。
本文提供独立本地测试套件，调度标记为false，不注册任何任务，也不向外部发送结果。不启用Vibe、不调用模型，不声称CoTrading已有定时服务。它验证的是下载实现的控制流，包括测试中故意破坏的变体必须被识别；这些变体只用于检验测试有效性，不是可供正式流程开启的绕过开关。
从流程设计走到可观察试跑
设计说明可以写“先刷新、再验证、再筛选，成功才发布”，试跑则要观察这些动作真正发生。程序用不同方法执行refresh、validate、screen和内存publish，每次实际调用时记录事件，测试拿事件与字面预期顺序比较。不能由任务最后自己总结“我做过刷新”，再把这段总结当刷新证据。
合成合同为固定UTC+08时区、16:00之后允许执行，日历只设2026年10月20、21日开市，24日休市。Python datetime文档支持带时区触发解析，日历本身不是官方交易所资料。真实集成另需核对日历来源和数据到达政策，不能从几个合成日期推出真实市场时段都被覆盖。
股票池为AAA和BBB，每份合格数据都要包含两只、正确日期、有限正PE。规则为PE小于20，AAA25不通过，BBB18通过。数值故意简单，便于把注意力放在时间、失败分支和重复执行，而不是研究策略是否有效。相同名单在多个情形下都可能出现，正好说明只核对最终候选不够。
运行前写好可观察预期
每个场景预先定义触发时间、数据载荷、期望状态、实际方法预期轨迹和累计产物数。逻辑时段用screen-v1:2026-10-20这类固定标识，不用随机运行号。同一成功会话的两次触发不能变成两个产物；失败尝试不应消费时段，修复数据后才能在同日完成，这些都要写成断言而不是操作建议。
Python unittest提供样例使用的断言方法。虽然套件以一个小runner执行，预期轨迹与数量仍作为独立测试数据。不能拿刚返回的实际值自动生成expected，否则少一次刷新或多一次发布都会“自己证明自己正确”。输入、预期、实际和差异应分别保存，方便复查哪条合同没满足。
最终名单不足以做唯一判定。坏实现可能跳过刷新，却因旧数据恰好相同仍选出BBB；可能先发布空结果再返回blocked；也可能把同一个正确名单发两遍。状态文本与候选巧合相同，真实调用、时段身份和产物基数却不同，试跑必须同时观察这些层面，不能只奖励一个看起来合理的答案。
用同一任务状态回放六个场景
第一场景为20日08:00，返回not_due，没有数据调用，产物零。它证明提前触发不会过早刷新或发布。第二场景20日16:30传入正确20日数据，返回success，顺序为刷新、验证、筛选、发布，累计产物一个，时段为20日，候选BBB。预期调用列表是明确字面值，不来自程序自动总结。
第三场景20日17:00再次请求，返回duplicate，调用列表空，产物仍一个。第四场景24日16:30，返回closed，也没有调用。这分别测试成功时段去重与非交易日判断，不能都归为供应商失败，更不能把休市返回解释成“今日没有股票符合条件”。数据步骤未执行与执行后零候选不是同一结果。
第五场景21日16:30删除AAA的PE。真实流程先刷新21日数据，再验证失败，轨迹只有刷新和验证，没有screen与publish，状态blocked，产物仍一个，21日时段未消费。测试不只要求错误消息出现，还要求没有任何新结果落入outputs。若坏数据被转成空名单发布，也必须被发现。
第六场景21日16:45提供修复数据，四步全部执行，成功后累计两个产物，标识恰好20日和21日各一个。它在同一对象状态内检验前次失败没有把当天错误标完；如果每个场景都新建对象，可能掩盖这种恢复问题。两份成功名单都为BBB，但日期各自明确，不能合并或重复计数。
actual = job.run(trigger, payload)
case.assertEqual(actual, expected_status)
case.assertEqual(job.trace, expected_trace)
case.assertEqual(len(job.outputs), expected_count)下载完整示例。使用Python 3.12+、标准库和合成数据，运行python R556.py。输出每场景的实际轨迹与产物数量，文件完全独立，不依赖其他教程下载，不需要调度器、联网、凭证或模型安装。
反过来破坏实现，检查测试能否发现
第一个故意变异是绕过重复抑制。20日第二次触发会再次执行并尝试发布，套件在状态或调用断言处抓住异常，不能因为第二份名单仍是BBB就放过。固定累计产物数量也能发现重复外部效果。这里是测试替身上的故障注入，不代表正式系统应暴露“忽略去重”选项给普通使用者。
第二个变异跳过refresh方法，直接把fixture传给下游。名单仍可能正确，但预期刷新事件消失，字面轨迹断言失败。它检验套件是否真正在核对依赖链，而不是只看最终答案。真实市场平静的一天，旧数据与新数据数值也可能一致，所以不能通过数值没有变化推断刷新已经发生。
第三个变异在验证失败分支里先publish，然后照样返回blocked。表面错误状态很安全，实际已经新增产物并消费时段。缺字段场景通过额外发布事件和数量变化识别它。只测最终状态会漏掉这种问题，错误消息也不能撤销校验前已经发生的副作用，因此“先验后放行”必须通过实际调用与产物共同验证。
修复后使用相同输入再次回放
runner断言三个变异全部被抓住，然后运行未破坏实现，六场景证据应与最初干净基线一致。保留基线、变异失败和修复回放，不用最后成功覆盖历史。只有最终测试通过，不能证明套件真的能发现预定缺陷；故障注入记录直接展示测试在哪一步识别了坏实现，这是验收的一部分。
数字另设边界：Python Decimal包含特殊值，脚本把NaN、正无穷、负无穷依次注入PE，都必须在产生输出前阻断。这测试数据内容有效性，六场景测试时点和状态转换，两组不能互相替代。实际来源还可能有单位或年度错配，需要按具体字段合同补充，不能把当前几个断言说成穷尽验证。
准确说明证据覆盖范围
结果证明这份本地实现对给定日历、时间、载荷和变异集合的行为，不测试真实调度引擎、交易日历服务、行情供应商、持久层或消息投递。以后连接这些组件时，分别在真实边界增加验证，同时保留相同逻辑时段、步骤轨迹和产物要求。不能把模拟发布截图或合成JSON当成线上服务正在运行的证明。
实际启用方案还需时区配置、规则版本、输入合同、重试政策、持久去重与发布目的地等具体实现，并另行授权。本文停在可执行试跑：六场景通过、三个故意缺陷被发现、修复回放一致，调度始终关闭。用户能够下载并核对方法，但不需要为了读教程启动任何后台任务，也不会影响现有服务。
试跑报告可按场景列输入、预期、实际状态、实际调用、累计产物与差异。失败时先定位最早不一致步骤，再修实现或纠正经审阅的预期；不能为了全绿直接删掉不方便的场景。新规则、日历政策或数据字段加入后，保留旧场景作为回归，再增加真正受影响的边界，使测试始终对应用户会依赖的行为。
维护能够独立发现问题的预期
场景输入与期望值最好由不同步骤核对，尤其是逻辑时段和累计数量。错误实现若把输出日期写成触发服务器本地日期，名单可能仍对；在接入真实时区转换时，需要增加跨日案例，不能仅复用这份固定偏移测试。当前套件明确只验固定UTC+08合同，没有声称覆盖夏令时或所有市场。
变异失败不应污染下一次干净回放。每个变异建立独立对象，修复验证再建立干净对象，让基线比较能够重复。与此同时，六个正常场景共用同一对象，专门检验去重与失败恢复状态。隔离和共享分别服务不同测试目的，随意每次清空状态可能使重复发布错误永远不出现。
常见问题
只看最终名单正确够吗？
不够，跳刷新、陈旧数据或重复发布都可能产生相同名单，需要核对调用、日期与数量。
文件会启动后台调度吗？
不会，只执行一次本地回放和故障测试，调度关闭。