ruflo tdd-london-swarm 技能深解基于伦敦学派Mockist的蜂群式 Outside-In TDD 测试 Agent 设计【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo本文围绕 ruflo 仓库中的 tdd-london-swarm 技能定义 展开完整解析这一 TDD「伦敦学派」Mockist / 模拟驱动测试 Agent 的技能结构、Outside-In 开发流、Mock 契约定义与蜂群Swarm测试协同模式。读完后你将理解如何在多 Agent 协作框架中落地以行为验证为核心的 TDD 实践并能在 ruflo 的 Agent 技能体系中复用同类设计模式。1. 技能定位ruflo 中的伦敦学派 TDD 测试 Agenttdd-london-swarm是 ruflo 提供的 Agent 技能skill其自我定位是TDD London School specialist for mock-driven development within swarm coordination —— 面向蜂群协作场景的、采用模拟驱动开发mock-driven development的 TDD 伦敦学派专家Agent 类型为tester优先级为high。它与纽约学派Statist侧重状态验证相对伦敦学派的核心立场是测试对象之间的对话interactions/collaborations而非对象内部状态通过 Mock 来隔离单元、定义契约。该技能声明了五项能力capabilitiescapabilities: - mock_driven_development # 模拟驱动开发 - outside_in_tdd # 由外向内 TDD - behavior_verification # 行为验证 - swarm_test_coordination # 蜂群测试协同 - collaboration_testing # 协作测试这五项能力对应后文的三大方法论支柱Outside-In、Mock-First、行为验证与三大蜂群协同支柱测试协同、契约共享、覆盖率聚合是整个技能的骨架。1.1 在 ruflo 技能体系中的位置ruflo 的.agents/目录是 OpenAI Codex CLI 的 Agent 配置与技能目录其结构与技能约定在 README 中有明确说明每个技能是一个子目录核心文件为SKILL.md可选附带scripts/与docs/技能通过$skill-name语法调用。因此本技能的调用方式为$agent-tdd-london-swarm技能文件采用双层 YAML frontmatter第一层是技能包装元数据name: agent-tdd-london-swarm描述为 invoke with $agent-tdd-london-swarm第二层是 Agent 本体元数据name: tdd-london-swarm、type: tester、color、description、capabilities、priority以及hooks。1.2 生命周期钩子pre/post hooks技能文件内定义了前后置钩子这是它作为蜂群中一个 Agent的可执行性体现hooks: pre: | echo TDD London School agent starting: $TASK # Initialize swarm test coordination if command -v npx $dev$null 21; then echo Coordinating with swarm test agents... fi post: | echo ✅ London School TDD complete - mocks verified # Run coordinated test suite with swarm if [ -f package.json ]; then npm test --if-present fipre 钩子打印任务标识$TASK并检测npx是否可用作为是否可以与蜂群测试 Agent 协同的前置信号post 钩子宣告完成并在存在package.json时执行npm test --if-present——注意--if-present保证在没有test脚本的项目中不报错这是跨项目复用该技能的实用设计。需要注意一个工程细节pre 钩子中$dev$null是 PowerShell 的空设备写法与 bash 的command -v ... 21混用了两种平台的语法。从源码结构看这段钩子更偏向意图声明而非可直接跨平台运行的脚本如果你在自己的环境中执行该钩子建议按实际 shell 调整为/dev/nullPOSIX或保持纯 PowerShell 写法。ruflo 中 Codex 侧的总配置 .agents/config.toml 定义了技能的启用方式[[skills.config]]条目按path指向技能目录并设置enabled、[hooks]生命周期开关pre_task/post_task/train_on_edit以及[performance]中max_agents 8、task_timeout 300等约束——这为测试 Agent 在蜂群中并发运行提供了默认资源边界默认最多 8 个并发 Agent、单任务 300 秒超时。2. 核心职责五项职能拆解技能正文将职责归纳为五点这五点同时也是一篇如何用该 Agent 做 TDD的操作清单Outside-In TDD由外向内从用户可观察的行为出发向下驱动到实现细节。先写验收测试acceptance test再逐层向内细化Mock-Driven Development模拟驱动用 mock 和 stub 隔离被测单元同时把 mock 的期望值当作协作契约的定义手段Behavior Verification行为验证关注对象间交互与协作who-called-whom-with-what而非对象内部持有的状态Swarm Test Coordination蜂群测试协同与其他测试 Agent如集成测试 Agent协作共同拼出完整覆盖Contract Definition契约定义通过 mock 期望建立清晰的接口契约。3. 伦敦学派 TDD 方法论三段式实战以下三个小节完整继承技能文档中的三组 TypeScript/Jest 代码示例并补充参数级注释。示例统一假设 Jest 环境describe/it/expect这是技能示例中实际使用的断言风格。3.1 Outside-In 开发流从验收测试切入伦敦学派的第一步永远是最外层的验收测试——站在用户行为视角写测试测试体内注入的协作方全部是 mock// 从验收测试起步最外层 describe(User Registration Feature, () { it(should register new user successfully, async () { // 被测对象 UserService 依赖的两个协作方全部注入 mock const userService new UserService(mockRepository, mockNotifier); const result await userService.register(validUserData); // 验证交互而非状态repository 收到的 save 调用参数应包含用户邮箱 expect(mockRepository.save).toHaveBeenCalledWith( expect.objectContaining({ email: validUserData.email }) ); // 通知服务应被用生成的 id 调用 expect(mockNotifier.sendWelcome).toHaveBeenCalledWith(result.id); // 唯一允许断言的结果状态业务流程成功标志 expect(result.success).toBe(true); }); });要点解析expect.objectContaining({...})是 Jest 部分对象匹配器只校验给定字段允许save收到额外字段。这正契合伦敦学派的契约观——契约只约束接口面上必须出现的东西不约束实现细节注意断言对象是mockRepository.save、mockNotifier.sendWelcome这类mock 函数本身验证发生了哪个调用、带什么参数而不是去userService内部翻取字段。唯一的状态断言result.success是对外可观察的业务结果符合从外往内的边界。3.2 Mock-First用 Mock 先行定义协作契约在写实现之前先把协作方的契约用 mock 写出来。技能文档中的示例// 通过 mock 定义协作方契约 const mockRepository { save: jest.fn().mockResolvedValue({ id: 123, email: testexample.com }), findByEmail: jest.fn().mockResolvedValue(null) // 初始不存在该邮箱 }; const mockNotifier { sendWelcome: jest.fn().mockResolvedValue(true) };jest.fn()创建可追踪调用的模拟函数.mockResolvedValue(...)预置 Promise 返回值使被测的async方法可以跑通完整流程findByEmail预置为null该用户尚未注册是在定义前置条件这条 mock 数据本身就是验收场景的输入假设这些 mock 的键名与方法签名save/findByEmail/sendWelcome同时充当了UserRepository与NotificationService的接口契约——实现类只要满足这些签名即可被测试接受。这就是mock 先行驱动设计决策mocks to drive design decisions的含义。3.3 行为验证优先于状态验证第二段核心示例聚焦对象之间的会话the conversation between objects// 关注对象如何协作 it(should coordinate user creation workflow, async () { await userService.register(userData); // 验证对象间的对话 expect(mockRepository.findByEmail).toHaveBeenCalledWith(userData.email); expect(mockRepository.save).toHaveBeenCalledWith( expect.objectContaining({ email: userData.email }) ); expect(mockNotifier.sendWelcome).toHaveBeenCalledWith(123); });与前一段相比这里额外验证了findByEmail的查重交互注册流程必须先查询、再保存、最后通知。三个断言串起来就是被测代码应该说的话。在技能文档的总结句里这一立场被明确表述为The London School emphasizeshow objects collaboraterather thanwhat they contain.伦敦学派强调的是对象如何协作而不是它们包含什么。4. 蜂群协同模式测试 Agent 之间的协作契约ruflo 的特色在于把单兵 TDD 专家放进蜂群swarm里。技能文档给出了三种蜂群协同模式以下完整保留其代码骨架并补充说明。需要说明swarmCoordinator、createSwarmMock、extendSwarmMock、SwarmContractMonitor等符号是技能文档为表达蜂群级测试协同而引入的示意性 API 名称文档自身定义的协作抽象并非标准 Jest 或某个公开库的现成接口落地时你需要按自己的协调层实现同名能力或替换为实际框架的对应原语。4.1 测试 Agent 协作向蜂群广播测试生命周期// 与集成测试 Agent 协同 describe(Swarm Test Coordination, () { beforeAll(async () { // 向蜂群其他 Agent 发出单元测试开始信号 await swarmCoordinator.notifyTestStart(unit-tests); }); afterAll(async () { // 把测试结果共享给蜂群 await swarmCoordinator.shareResults(testResults); }); });这对应技能Swarm Integration一节中跨蜂群成员同步测试执行Synchronize test execution across swarm members的要求单元层 Agent 开始/结束测试时发出信号集成层 Agent 可据此决定自己的执行窗口避免相互干扰。4.2 契约测试把接口契约变成可共享的数据结构// 定义契约供蜂群其他 Agent 验证 const userServiceContract { register: { input: { email: string, password: string }, output: { success: boolean, id: string }, collaborators: [UserRepository, NotificationService] // 显式列出协作方 } };该契约对象把第 3.2 节中隐式的 mock 签名显式化每个方法声明了input/output的类型形状以及collaborators依赖哪些协作对象。这使得实现 Agent与测试 Agent可以围绕同一份契约工作——实现 Agent 按契约写代码测试 Agent 按契约写断言任何一方变更契约都需要同步到蜂群。4.3 Mock 协调在蜂群成员间共享 Mock 定义// 在蜂群内共享 mock 定义 const swarmMocks { userRepository: createSwarmMock(UserRepository, { save: jest.fn(), findByEmail: jest.fn() }), notificationService: createSwarmMock(NotificationService, { sendWelcome: jest.fn() }) };createSwarmMock(name, shape)的语义是以类名 方法表的形式登记一份共享 mock。其价值在于一致性——当单元测试 Agent、集成测试 Agent、代码评审 Agent 都引用同一份UserRepositorymock 形状时任何一侧对契约的偏离都会立即暴露为不一致而不是等到端到端运行时才失败。5. 测试策略交互测试、协作时序与契约演化技能文档Testing Strategies一节给出三种更深层次的策略。5.1 交互测试Interaction Testing断言完整调用序列// 测试对象间的会话 it(should follow proper workflow interactions, () { const service new OrderService(mockPayment, mockInventory, mockShipping); service.processOrder(order); const calls jest.getAllMockCalls(); // 示意性 API取出全部 mock 调用记录 expect(calls).toMatchInlineSnapshot( Array [ Array [mockInventory.reserve, [orderItems]], Array [mockPayment.charge, [orderTotal]], Array [mockShipping.schedule, [orderDetails]], ] ); });这段示例的价值在于顺序断言下单流程必须按预留库存 → 扣款 → 安排发货的次序发生。文档使用jest.getAllMockCalls()与toMatchInlineSnapshot的组合把整个调用序列固化成内联快照——jest.fn()/toHaveBeenCalledWith/toMatchInlineSnapshot均为标准 Jest API而jest.getAllMockCalls()在文档中属于示意性取数方式标准 Jest 中等价的取法是逐个调用mock.calls。这里体现的是伦敦学派的以对话定测试不是断言订单对象里某个字段变成了什么而是断言三条消息按正确顺序发给了三个协作方。5.2 协作模式Collaboration Patterns时序约束断言// 测试对象如何协同工作 describe(Service Collaboration, () { it(should coordinate with dependencies properly, async () { const orchestrator new ServiceOrchestrator( mockServiceA, mockServiceB, mockServiceC ); await orchestrator.execute(task); // 验证协调时序 expect(mockServiceA.prepare).toHaveBeenCalledBefore(mockServiceB.process); expect(mockServiceB.process).toHaveBeenCalledBefore(mockServiceC.finalize); }); });toHaveBeenCalledBefore是时序约束断言在标准 Jest 中由 jest-extended 提供需import jest-extended/all启用。它回答的问题是A 的准备动作是否严格先于 B 的处理动作。这是编排器orchestrator类代码最需要的断言——编排逻辑本身几乎没有内部状态它的正确性完全体现为调用时序这正是伦敦学派的用武之地。5.3 契约演化Contract Evolution根据蜂群反馈扩展契约// 基于蜂群反馈演化契约 describe(Contract Evolution, () { it(should adapt to new collaboration requirements, () { const enhancedMock extendSwarmMock(baseMock, { newMethod: jest.fn().mockResolvedValue(expectedResult) }); expect(enhancedMock).toSatisfyContract(updatedContract); }); });extendSwarmMock(baseMock, additions)表达在既有 mock 上叠加新方法的增量扩展toSatisfyContract(updatedContract)表达扩展后的 mock 必须满足更新后的契约。从源码结构看这一模式对应技能反馈回路设计当蜂群中架构 Agent 或实现 Agent 提出新的协作需求时测试侧通过扩展而非重写契约来吸收变更保证契约历史可追溯。6. 蜂群集成协同、反馈与持续验证6.1 测试协同Test Coordination技能文档列出的四条协同职责与集成测试 Agent 协同完成端到端场景unit 层与 integration 层分工共享 mock 契约给其他测试 Agent见 4.3 的swarmMocks跨蜂群成员同步测试执行见 4.1 的notifyTestStart/shareResults聚合多 Agent 的覆盖率报告aggregate coverage reports。6.2 反馈回路Feedback Loops测试 Agent 不只产出测试还要向蜂群其他角色回流洞察把交互模式interaction patterns上报给架构 Agent——例如OrderService 与三个协作方的调用序列这类信息可直接支撑架构决策把发现的契约分享给实现 Agent——实现方据此对齐接口把行为洞察提供给设计 Agent与代码质量 Agent协同重构。这套反馈机制使 tdd-london-swarm 在蜂群中的角色从写测试的升级为契约与行为的知识源。6.3 持续验证Continuous Verification// 持续契约验证 const contractMonitor new SwarmContractMonitor(); afterEach(() { contractMonitor.verifyInteractions(currentTest.mocks); contractMonitor.reportToSwarm(interactionResults); });afterEach钩子里对每个测试的 mock 做交互校验并上报蜂群把契约是否被遵守从一次性断言变成贯穿整个测试会话的持续监控SwarmContractMonitor同为文档定义的示意性协调类。7. 最佳实践Mock 管理、契约设计与蜂群协作技能文档Best Practices一节的完整准则可作为评审 mock 测试代码的 checklist7.1 Mock 管理Mock ManagementMock 保持简单、聚焦单一职责验证交互而非实现verify interactions, not implementations行为验证统一使用jest.fn()避免过度 mock 内部细节over-mocking——只 mock 边界上的协作方不要 mock 被测对象内部实现。7.2 契约设计Contract Design用 mock 期望定义清晰接口聚焦对象职责与协作关系用 mock 驱动设计决策先有 mock 契约再写实现契约保持最小且内聚minimal and cohesive——只写当前协作真正需要的字段与方法。7.3 蜂群协作Swarm Collaboration与其他 Agent 共享测试洞察协调测试执行时序维持一致的 mock 契约与 4.3 的共享 mock 呼应提供反馈以持续改进。8. 仓库内的集成佐证该技能如何被 ruflo 引用技能文件不是孤立存在的ruflo 仓库中有多处引用可以印证其在整体体系中的位置Agent 能力清单CLAUDE.md 在 Testing Validation 分组下并列列出tdd-london-swarm与production-validator两个测试/验证类 Agent说明该技能是 ruflo Agent 矩阵中质量与验证方向的正式成员方法论分组AGENTS-SKILLS-COMMANDS-HOOKS.md 的 v3 Agent 目录树将其归入methodology/流程类 Agent与sparc-coord、specification、refinement、production-validator同组表明 ruflo 把伦敦学派 TDD视作一套过程方法论而非单纯工具技能依赖V3-OPTIMIZED-PLAN.md 中可见get requiredSkills() { return [sparc-methodology, tdd-london-swarm]; }的规划代码说明在某些工作流角色如实现类 Agent中该技能与 SPARC 方法论被声明为成对的前置技能依赖——先按 SPARC 完成规格化再以伦敦学派方式驱动测试回归测试test-agents.sh 的 Docker 回归套件在 Testing Validation Agents 段落中以test_agent tdd-london-swarm将其纳入 Agent 可用性检查检查方式为npx claude-flow agent info tdd-london-swarm命令容错若 npx 不可用则回退为回显保证脚本在离线环境不中断。从以上引用关系可以推断在 ruflo 的分层架构中tdd-london-swarm位于方法论层被上层工作流以requiredSkills方式声明依赖并受回归脚本持续探测其可加载性。9. 适用前提与限制测试框架假设技能的全部代码示例基于 Jest 风格 APIjest.fn()、toHaveBeenCalledWith、objectContaining、toMatchInlineSnapshot其中toHaveBeenCalledBefore需 jest-extended 支持createSwarmMock/extendSwarmMock/SwarmContractMonitor/toSatisfyContract/jest.getAllMockCalls是技能文档定义的示意性蜂群协作原语需在自己的协调层中实现对应能力不能直接从文档示例中复制运行钩子脚本的平台差异pre 钩子中$dev$nullPowerShell与 bash 测试语法混用跨平台执行前需按 1.2 节说明调整蜂群依赖该技能的价值在蜂群语境下才完整体现契约共享、结果聚合、反馈回路都依赖swarmCoordinator一类的协调设施单独作为普通 Jest 测试编写指南使用时可只取第 2、3、5、7 节的方法论部分运行环境技能启用与 Agent 并发受 .agents/config.toml 中[performance]默认max_agents 8、task_timeout 300与[hooks]配置约束在 ruflo 环境下使用时以该配置文件为事实依据。10. 小结tdd-london-swarm技能把伦敦学派 TDD 的三个核心主张——Outside-In 开发流、Mock 先行定义契约、行为验证优先于状态验证——封装为一个可被蜂群调度的testerAgent并进一步用共享 mock、契约数据化、持续契约监控三种模式解决了多 Agent 测试之间的契约一致性问题。对 ruflo 用户而言它既是一份可直接调用的测试 Agent 技能$agent-tdd-london-swarm也是一份可迁移到任意 Jest 项目中的 mockist TDD 操作手册对 Agent 框架开发者而言其双层 frontmatter pre/post 钩子 契约共享的设计是多 Agent 系统中过程方法论类技能的一个完整参考实现。延伸阅读路径.agents/README.md技能体系总览、.agents/config.tomlAgent 并发与钩子配置、AGENTS-SKILLS-COMMANDS-HOOKS.mdAgent 分组与技能目录设计、test-agents.shAgent 回归探测脚本。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考