ruflo 中的 TDD London School 测试 AgentSwarm 协同下的 Mock 驱动测试实战指南【免费下载链接】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 项目Claude-Flow v3中 tdd-london-swarm.md 测试 Agent 的技术解析与实践指南。文章围绕该 Agent 所遵循的 London SchoolMockistTDD 方法讲解如何在多 Agent Swarm 协同场景下通过 Outside-In 开发、Mock-First 测试与行为验证Behavior Verification建立高质量、可演进的测试体系。读完本文你将掌握该测试 Agent 的完整职责边界、核心方法学、Swarm 协同模式并能直接复用仓库中 claude-flow/testing 提供的 Mock 工厂、行为断言与自定义 Matcher 编写可运行的 London School 风格测试。一、Agent 定位Swarm 中的测试专家在 ruflo 的 15-Agent Swarm 架构中测试职责由专项 Agent 承担。该 Agent 的定位文件位于 tdd-london-swarm.md其 Frontmatter 定义了身份与能力--- name: tdd-london-swarm type: tester color: #E91E63 description: TDD London School specialist for mock-driven development within swarm coordination capabilities: - mock_driven_development - outside_in_tdd - behavior_verification - swarm_test_coordination - collaboration_testing priority: high ---这份配置声明了该 Agent 的核心能力集合Mock 驱动开发、Outside-In TDD、行为验证、Swarm 测试协同与协作测试并以priority: high标记其在质量保障链路中的关键地位。1.1 生命周期 Hook进入与退出的协同动作Frontmatter 中的hooks定义了 Agent 在任务开始pre与结束post时的自动行为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 fipreHook 在任务启动时打印启动信息并探测npx环境以初始化 Swarm 协同postHook 在测试完成后执行收尾若当前目录存在package.json则自动运行npm test --if-present将验证动作闭环回测试套件本身。这一设计体现了测试 Agent 自身也受 CI 纪律约束的工程理念。1.2 在 15-Agent 架构中的协作位置从源码 agent-registry.ts 的默认注册表可以看到测试能力被拆分为两个 Agentagent-4security-testerSecurity testing using TDD London School methodology依赖 agent-2security-architect负责安全模块的测试编写与执行agent-13tdd-test-engineerTDD London School methodology implementationdomain: quality能力为test-writing是方法论的总协调者正如 TDD-LONDON-SCHOOL-PLAN.md 所述——15 个 Agent 均遵循该方法论agent-13 是主要协调者primary coordinator。此外agent-15release-engineer声明了对 agent-13 的依赖说明发布流程的测试门禁由该测试 Agent 的方法论与产物支撑形成了测试先行 → 实现 → 发布的依赖链。二、London School 与 Classical TDD 的本质差异要理解该 Agent 的行为准则必须先厘清 TDD 的两大学派。仓库中的实施计划文档 TDD-LONDON-SCHOOL-PLAN.md 给出了清晰的对照维度London School本 Agent 采用Classical / Detroit经典派关注点行为与对象间交互状态验证Mock 策略Mock 所有协作者最小化 Mock演进方向Outside-In由外向内Inside-Out由内向外粒度细粒度单元测试粗粒度耦合对象测试与设计耦合测试与行为耦合重构影响可能破坏测试测试存活于重构实施计划给出了选择 London School 的四点理由这在 Swarm 多 Agent 协作场景下尤其关键前置强制清晰接口设计Mock 所有协作者意味着每个协作点都必须先定义接口契约支持并行开发依赖被 Mock 后多个 Agent 可并行实现各自模块早期暴露集成问题交互契约在单元层面即被验证与 Swarm Agent 隔离架构契合每个 Agent 本身就是独立单元天然适合交互级测试。三、核心方法论三条铁的纪律该 Agent 的Core Responsibilities定义了五项职责可归纳为三条方法论支柱Outside-In 开发流、Mock-First 契约定义、行为验证优先于状态验证。3.1 Outside-In从验收测试向内驱动第一条纪律是从用户行为出发向下驱动到实现细节。以文档中的用户注册场景为例// Start with acceptance test (outside) describe(User Registration Feature, () { it(should register new user successfully, async () { const userService new UserService(mockRepository, mockNotifier); const result await userService.register(validUserData); expect(mockRepository.save).toHaveBeenCalledWith( expect.objectContaining({ email: validUserData.email }) ); expect(mockNotifier.sendWelcome).toHaveBeenCalledWith(result.id); expect(result.success).toBe(true); }); });注意这个测试的写法被测对象UserService的依赖mockRepository、mockNotifier全部是 Mock断言关注的是协作是否发生save被调用、sendWelcome被调用而不是仓库内部如何存储数据。实施计划 TDD-LONDON-SCHOOL-PLAN.md 中的验收测试示例与此一脉相承——UnifiedSwarmCoordinator的测试从coordinateSwarm({ agents: 15, topology: mesh })这个外部可观察行为切入断言completedTasks 15与consensusAchieved true。3.2 Mock-First用 Mock 定义协作契约第二条纪律是在写实现之前先通过 Mock 声明协作者的接口契约// Define collaborator contracts through mocks const mockRepository { save: jest.fn().mockResolvedValue({ id: 123, email: testexample.com }), findByEmail: jest.fn().mockResolvedValue(null) }; const mockNotifier { sendWelcome: jest.fn().mockResolvedValue(true) };在 ruflo 的实际源码中这套Mock 即契约的模式被工程化为一套完整的 Mock 工厂体系位于 create-mock.ts。其中核心的createMockT通过Proxy在运行时按需生成vi.fn()任何被访问的方法都会自动成为可追踪的 Mock无需手写完整接口实现export function createMockT extends object(): MockedInterfaceT { return new Proxy({} as MockedInterfaceT, { get: (target, prop: string | symbol) { if (typeof prop string !(prop in target)) { (target as Recordstring | symbol, unknown)[prop] vi.fn(); } return (target as Recordstring | symbol, unknown)[prop]; }, }); }同一文件还提供了针对不同场景的变体createDeepMockT通过缓存与链式mockReturnValue支持嵌套对象访问适合复杂接口createSpyMockT包装真实对象保留原始行为同时开启行为验证适合部分真实、部分验证的场景createMockWithBehaviorT为方法直接注入预设实现例如findById: async (id) ({ id, name: Test })createRetryMockT首次调用抛错、后续调用成功专门用于测试重试与容错逻辑createSequenceMockT按调用次序返回不同值用于测试有状态交互。更值得关注的是InteractionRecorder类它可同时跟踪多个 Mock 的所有调用并按时间戳记录调用顺序最终通过getInteractionOrder()输出如[repo.save, notifier.notify]的调用序列——这正是文档 3.3 节行为验证与 Swarm 协同测试的底层支撑。3.3 行为验证关注对象如何对话第三条纪律的核心论断是London School 强调对象如何协作而非对象内部包含什么。文档给出了工作流交互测试示例it(should coordinate user creation workflow, async () { await userService.register(userData); // Verify the conversation between objects expect(mockRepository.findByEmail).toHaveBeenCalledWith(userData.email); expect(mockRepository.save).toHaveBeenCalledWith( expect.objectContaining({ email: userData.email }) ); expect(mockNotifier.sendWelcome).toHaveBeenCalledWith(123); });更进一步文档展示了用toMatchInlineSnapshot精确锁定跨对象调用序列的模式OrderService 示例中依次断言mockInventory.reserve→mockPayment.charge→mockShipping.schedule以及用toHaveBeenCalledBefore验证协作时序expect(mockServiceA.prepare).toHaveBeenCalledBefore(mockServiceB.process); expect(mockServiceB.process).toHaveBeenCalledBefore(mockServiceC.finalize);ruflo 在 setup.ts 中通过expect.extend注册了toHaveBeenCalledWithInteraction校验精确调用参数与toHaveBeenCalledBefore校验 Mock 调用次序等自定义 Matcher使上述文档模式可直接落地为 Vitest 断言。配套的 assertions.ts 还提供了更丰富的行为断言工具assertCallSequence一次断言多个 Mock 按指定顺序、指定参数被调用assertContractCompliance验证实现对象是否满足契约定义接口合规测试assertEventPublished断言领域事件被发布且负载匹配assertNoSensitiveDataLogged安全断言——确保日志中不出现密码、Token 等敏感模式assertPerformanceTarget带预热期的性能断言返回平均/最小/最大耗时。四、Swarm 协同模式测试不再是孤军奋战文档的核心特色在于将测试活动置于 Swarm 协作语境中定义了三种协同模式。4.1 测试 Agent 协同生命周期信号的广播// Coordinate with integration test agents describe(Swarm Test Coordination, () { beforeAll(async () { // Signal other swarm agents await swarmCoordinator.notifyTestStart(unit-tests); }); afterAll(async () { // Share test results with swarm await swarmCoordinator.shareResults(testResults); }); });这与仓库中 mock-factory.ts 提供的createMockSwarmCoordinator相呼应——该工厂生产的 Swarm 协调器 Mock 具备initialize、coordinate、broadcast、addAgent、removeAgent等方法并维护可检查的state含topology、agentCount、status等字段使测试代码可以真实驱动 Swarm 状态机变化。4.2 契约测试为其他 Agent 定义可验证的接口// Define contracts for other swarm agents to verify const userServiceContract { register: { input: { email: string, password: string }, output: { success: boolean, id: string }, collaborators: [UserRepository, NotificationService] } };契约对象同时声明了输入、输出与协作方这正是跨 Agent 并行开发的握手协议——实现方如 agent-6 core-implementer按契约实现测试方agent-13按契约验证assertContractCompliance则从测试侧确保实现没有遗漏任何约定方法。4.3 Mock 共享跨 Swarm 复用 Mock 定义// Share mock definitions across swarm const swarmMocks { userRepository: createSwarmMock(UserRepository, { save: jest.fn(), findByEmail: jest.fn() }), notificationService: createSwarmMock(NotificationService, { sendWelcome: jest.fn() }) };结合实施计划中的 Mock Factory Pattern 章节createMockT()基于mockDeep的泛化封装可以看到 ruflo 期望将 Mock 提升为团队级共享资产——所有 Agent 使用同一套工厂保证契约表述一致避免各 Agent 各自为政导致契约漂移。五、Swarm 集成反馈闭环与持续验证文档Swarm Integration部分定义了三个层次的集成机制测试协调Test Coordination与集成测试 Agent 协同覆盖端到端场景与其他测试 Agent 共享 Mock 契约跨 Swarm 成员同步测试执行聚合多 Agent 的覆盖率报告。反馈闭环Feedback Loops向架构 Agent 上报交互模式向实现 Agent 分享新发现的契约向设计 Agent 提供行为洞察与代码质量 Agent 协调重构。持续验证Continuous Verification// Continuous contract verification const contractMonitor new SwarmContractMonitor(); afterEach(() { contractMonitor.verifyInteractions(currentTest.mocks); contractMonitor.reportToSwarm(interactionResults); });注意SwarmContractMonitor是文档中给出的示意性 API在仓库中与之功能对应的是 create-mock.ts 内的InteractionRecorder——它以track(name, mock)注册 Mock、以getInteractions()导出全部调用记录并在每次用例结束后通过clear()重置天然适配afterEach中的持续验证模式。六、Agent 工作流与测试结构规范6.1 每个 Agent 的 TDD 工作流实施计划 TDD-LONDON-SCHOOL-PLAN.md 明确了每个 Agent 的八步循环从 Queen Coordinator 接收任务 → 编写失败验收测试 → 编写失败单元测试Mock 协作者→ 实现最小代码通过测试 → 在测试保持通过的前提下重构 → 重复步骤 3-5 直至验收测试通过 → 向 Queen Coordinator 汇报完成 → 用测试覆盖率更新 GitHub Issue。这套流程同时是测试即进度的可见化机制每个 Agent 的产出都以可运行、可验证的测试为凭证。6.2 单断言原则实施计划对断言纪律有明确示范TDD-LONDON-SCHOOL-PLAN.md// CORRECT: Multiple expects for same assertion it(should generate secure token, () { const token secureFoundation.generateSecureToken(32); expect(token).toHaveLength(64); // 32 bytes 64 hex chars expect(token).toMatch(/^[a-f0-9]$/); }); // INCORRECT: Multiple unrelated assertions it(should handle authentication, async () { const hash await auth.hashPassword(test); expect(hash).toBeDefined(); // Assertion 1 const token auth.generateToken(); expect(token).toHaveLength(64); // Assertion 2 - SEPARATE TEST! const valid await auth.verify(token); expect(valid).toBe(true); // Assertion 3 - SEPARATE TEST! });同一逻辑单元的多个expect是允许的但无关断言必须拆分为独立用例——这保证了失败时定位精准也符合行为验证对单一交互场景的聚焦要求。6.3 测试目录结构实施计划给出了与 Swarm 模块边界对齐的测试目录规范节选__tests__/ ├── unit/ │ ├── security/ # agent-2/3/4 模块 │ ├── core/ # agent-5/6 模块task-manager、lifecycle-manager 等 │ ├── memory/ # agent-7 模块agentdb-adapter 等 │ ├── swarm/ # agent-8 模块unified-coordinator、consensus-engine 等 │ ├── mcp/ # agent-9 模块 │ └── neural/ # agent-12 模块 ├── integration/ # 跨模块流security-flow、swarm-coordination 等 ├── e2e/ # CLI 命令、swarm 执行、完整工作流 ├── acceptance/ # unified-coordinator、security-compliance、性能目标 ├── performance/ # 启动时间、内存操作、swarm 延迟基准 ├── fixtures/ # agents.ts、tasks.ts、memory-entries.ts、configurations.ts ├── mocks/ # event-bus.mock.ts、agent-pool.mock.ts 等 └── helpers/ # create-mock.ts、test-application.ts、swarm-instance.ts、assertions.ts值得说明的是仓库中 claude-flow/testing 包已经将其中大部分目录落地为真实模块helpers/下有create-mock.ts、assertions.ts、assertion-helpers.ts、test-application.ts、swarm-instance.ts、test-utils.ts、setup-teardown.tsfixtures/下有agents.ts、tasks.ts、memory-entries.ts、configurations.tsmocks/下有mock-services.ts、mock-mcp-client.ts。包入口 index.ts 统一导出全部工具并基于 ADR-008 采用 Vitest 作为测试框架。七、集成到实际测试从文档到可运行代码文档强调用 jest.fn() 做行为验证并给出了契约演化示例extendSwarmMock、toSatisfyContract。结合仓库源码一个完整的 London School 风格用例可以这样组织import { describe, it, expect, beforeEach } from vitest; import { createMock, createMockEventBus, createMockTaskManager, createMockAgentLifecycle, createMockSwarmCoordinator, assertCallSequence, assertEventPublished, } from claude-flow/testing; describe(TaskManager (London School), () { let eventBus: ReturnTypetypeof createMockEventBus; let taskManager: ReturnTypetypeof createMockTaskManager; let agentLifecycle: ReturnTypetypeof createMockAgentLifecycle; beforeEach(() { eventBus createMockEventBus(); taskManager createMockTaskManager(); agentLifecycle createMockAgentLifecycle(); }); it(应该按序完成 创建→分配→执行 的协作流, async () { const task await taskManager.create({ name: t1, type: test }); await taskManager.execute(task.id); // 行为验证事件总线确实收到事件 assertEventPublished(eventBus.publish, task_submitted); }); it(should verify agent spawn lifecycle interactions, async () { const result await agentLifecycle.spawn({ type: tester, name: tdd-london, capabilities: [test-writing], }); expect(result.success).toBe(true); expect(agentLifecycle.spawn).toHaveBeenCalled(); }); });上述代码可直接运行于 ruflo 的 v3 工作区依赖 Vitest 与 claude-flow/testing 包展示了文档方法论与仓库工具链的完整衔接Mock 工厂负责契约定义事件 Mock 负责行为记录断言工具负责行为验证。八、最佳实践总结文档末尾的 Best Practices 是整套方法论的浓缩结合仓库实现可归纳为三条行动准则Mock 管理保持 Mock 简单聚焦避免过度 Mock 内部细节验证交互而非实现使用vi.fn()/jest.fn()追踪行为需要嵌套对象时使用createDeepMock需要保留真实行为时使用createSpyMock。契约设计通过 Mock 期望定义清晰接口input/output/collaborators三要素聚焦对象职责与协作关系用 Mock 驱动设计决策——接口在测试中先行定型保持契约最小化与内聚并用assertContractCompliance持续校验。Swarm 协作跨 Agent 共享测试洞察与 Mock 定义协调测试执行时序beforeAll广播开始、afterAll共享结果维护一致的 Mock 契约防止并行开发中的契约漂移通过InteractionRecorder/SwarmContractMonitor类机制为持续改进提供反馈数据。结语tdd-london-swarm 测试 Agent 的定位文档虽然只是一份 Agent 提示词System Prompt但它完整编码了一套可执行的工程方法论以 Outside-In 为方向、以 Mock 为契约工具、以行为验证为判据、以 Swarm 协同为执行环境。ruflo 仓库不仅在 实施计划 中给出了全量测试结构规划更通过 claude-flow/testing 包将方法论落成可直接引用的工厂函数、断言库与自定义 Matcher。理解并复用这套体系是参与 ruflo 多 Agent 开发时写出高质量测试的捷径——测试不再是开发的后置环节而是驱动每个 Agent 交付的先行契约。延伸阅读SWARM-OVERVIEW.md15-Agent Swarm 总览、AGENT-SPECIFICATIONS.md各 Agent 职责明细、framework.test.tsTesting 包冒烟测试。【免费下载链接】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），仅供参考