Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
proffesor-for-testing avatar

Tdd London Chicago

proffesor-for-testing/agentic-qe

  • 102 installs
  • 433 repo stars
  • Updated August 4, 2026
  • proffesor-for-testing/agentic-qe

tdd-london-chicago is a Claude Code skill for ai & agent building.

About

tdd-london-chicago is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.

  • tdd-london-chicago
  • AI & Agent Building
  • AI-coding skill

Tdd London Chicago by the numbers

  • 102 all-time installs (skills.sh)
  • +3 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #4,284 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/proffesor-for-testing/agentic-qe --skill tdd-london-chicago

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs102
repo stars★ 433
Last updatedAugust 4, 2026
Repositoryproffesor-for-testing/agentic-qe ↗

How do I helps with ai & agent building tasks.?

Helps with ai & agent building tasks.

Who is it for?

Best when you're working on ai & agent building and need structured help with tdd london chicago.

Skip if: Teams with no ai & agent building needs, or anyone wanting a generic chat assistant without this specific workflow.

When should I use this skill?

When you need to helps with ai & agent building tasks., or when tdd-london-chicago is a claude code skill for ai & agent building.

What you get

Structured output aligned to tdd-london-chicago: tdd-london-chicago, AI & Agent Building.

Files

SKILL.mdMarkdownGitHub ↗

Test-Driven Development: London & Chicago Schools

<default_to_action> When implementing TDD or choosing testing style: 1. IDENTIFY code type: domain logic → Chicago, external deps → London 2. WRITE failing test first (Red phase) 3. IMPLEMENT minimal code to pass (Green phase) 4. REFACTOR while keeping tests green (Refactor phase) 5. REPEAT cycle for next functionality

Quick Style Selection:

  • Pure functions/calculations → Chicago (real objects, state verification)
  • Controllers/services with deps → London (mocks, interaction verification)
  • Value objects → Chicago (test final state)
  • API integrations → London (mock external services)
  • Mix both in practice (London for controllers, Chicago for domain)

Critical Success Factors:

  • Tests drive design, not just verify it
  • Make tests fail first to ensure they test something
  • Write minimal code - no features beyond what's tested

</default_to_action>

Quick Reference Card

When to Use

  • Starting new feature with test-first approach
  • Refactoring legacy code with test coverage
  • Teaching TDD practices to team
  • Choosing between mocking vs real objects

TDD Cycle

PhaseActionDiscipline
RedWrite failing testVerify it fails, check message is clear
GreenMinimal code to passNo extra features, don't refactor
RefactorImprove structureKeep tests passing, no new functionality

School Comparison

AspectChicago (Classicist)London (Mockist)
CollaboratorsReal objectsMocks/stubs
VerificationState (assert outcomes)Interaction (assert calls)
IsolationLower (integrated)Higher (unit only)
RefactoringEasierHarder (mocks break)
Design feedbackEmerges from useExplicit from start

Agent Coordination

  • qe-test-generator: Generate tests in both schools
  • qe-test-implementer: Implement minimal code (Green)
  • qe-test-refactorer: Safe refactoring (Refactor)

---

Chicago School (State-Based)

Philosophy: Test observable behavior through public API. Keep tests close to consumer usage.

// State verification - test final outcome
describe('Order', () => {
  it('calculates total with tax', () => {
    const order = new Order();
    order.addItem(new Product('Widget', 10.00), 2);
    order.addItem(new Product('Gadget', 15.00), 1);

    expect(order.totalWithTax(0.10)).toBe(38.50);
  });
});

When Chicago Shines:

  • Domain logic with clear state
  • Algorithms and calculations
  • Value objects (Money, Email)
  • Simple collaborations
  • Learning new domain

---

London School (Mock-Based)

Philosophy: Test each unit in isolation. Focus on how objects collaborate.

// Interaction verification - test method calls
describe('Order', () => {
  it('delegates tax calculation', () => {
    const taxCalculator = {
      calculateTax: jest.fn().mockReturnValue(3.50)
    };
    const order = new Order(taxCalculator);
    order.addItem({ price: 10 }, 2);

    order.totalWithTax();

    expect(taxCalculator.calculateTax).toHaveBeenCalledWith(20.00);
  });
});

When London Shines:

  • External integrations (DB, APIs)
  • Command patterns with side effects
  • Complex workflows
  • Slow operations (network, I/O)

---

Mixed Approach (Recommended)

// London for controller (external deps)
describe('OrderController', () => {
  it('creates order and sends confirmation', async () => {
    const orderService = { create: jest.fn().mockResolvedValue({ id: 123 }) };
    const emailService = { send: jest.fn() };

    const controller = new OrderController(orderService, emailService);
    await controller.placeOrder(orderData);

    expect(orderService.create).toHaveBeenCalledWith(orderData);
    expect(emailService.send).toHaveBeenCalled();
  });
});

// Chicago for domain logic
describe('OrderService', () => {
  it('applies discount when threshold met', () => {
    const service = new OrderService();
    const order = service.create({ items: [...], total: 150 });

    expect(order.discount).toBe(15); // 10% off > $100
  });
});

---

Common Pitfalls

❌ Over-Mocking (London)

// BAD - mocking everything
const product = { getName: jest.fn(), getPrice: jest.fn() };

Better: Only mock external dependencies.

❌ Mocking Internals

// BAD - testing private methods
expect(order._calculateSubtotal).toHaveBeenCalled();

Better: Test public behavior only.

❌ Test Pain = Design Pain

  • Need many mocks? → Too many dependencies
  • Hard to set up? → Constructor does too much
  • Can't test without database? → Coupling issue

---

Agent-Assisted TDD

// Agent generates tests in both schools
await Task("Generate Tests", {
  style: 'chicago',      // or 'london'
  target: 'src/domain/Order.ts',
  focus: 'state-verification'  // or 'collaboration-patterns'
}, "qe-test-generator");

// Agent-human ping-pong TDD
// Human writes test concept
const testIdea = "Order applies 10% discount when total > $100";

// Agent generates formal failing test (Red)
await Task("Create Failing Test", testIdea, "qe-test-generator");

// Human writes minimal code (Green)

// Agent suggests refactorings
await Task("Suggest Refactorings", { preserveTests: true }, "qe-test-refactorer");

---

Agent Coordination Hints

Memory Namespace

aqe/tdd/
├── test-plan/*        - TDD session plans
├── red-phase/*        - Failing tests generated
├── green-phase/*      - Implementation code
└── refactor-phase/*   - Refactoring suggestions

Fleet Coordination

const tddFleet = await FleetManager.coordinate({
  workflow: 'red-green-refactor',
  agents: {
    testGenerator: 'qe-test-generator',
    testExecutor: 'qe-test-executor',
    qualityAnalyzer: 'qe-quality-analyzer'
  },
  mode: 'sequential'
});

---

Related Skills

  • agentic-quality-engineering - TDD with agent coordination
  • refactoring-patterns - Refactor phase techniques
  • api-testing-patterns - London school for API testing

---

Remember

Chicago: Test state, use real objects, refactor freely London: Test interactions, mock dependencies, design interfaces first Both: Write the test first, make it pass, refactor

Neither is "right." Choose based on context. Mix as needed. Goal: well-designed, tested code.

With Agents: Agents excel at generating tests, validating green phase, and suggesting refactorings. Use agents to maintain TDD discipline while humans focus on design decisions.

Gotchas

  • Agent skips Red phase and writes test + implementation together — enforce "test must fail first" by running test before writing code
  • London school over-mocking creates brittle tests that break on any refactor — mock at architectural boundaries, not every function
  • Chicago school tests become slow as integration scope grows — keep test boundaries tight
  • Agent defaults to jest.mock() for everything — prefer dependency injection for testability
  • Refactor phase is where agent cuts corners most — verify no behavior changes by checking test output is identical

Related skills

mattpocockSetup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196kopen.feishu.cnLark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402kjuliusbrusseeCavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7klarksuiteLark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16kxixu-meRunning Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72runcomfy-comCodex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10

FAQ

What does tdd-london-chicago do?

tdd-london-chicago is a Claude Code skill for ai & agent building.

When should I use tdd-london-chicago?

When you need to helps with ai & agent building tasks., or when tdd-london-chicago is a claude code skill for ai & agent building.

What are the main capabilities?

tdd-london-chicago; AI & Agent Building; AI-coding skill.

AI & Agent Buildingagents
Browse by category
AI & AgentsFrontend & DesignBackend & DataDev ToolsAutomationTesting & ReviewSecurityMonitoring & CloudDocs & Planning
Design & frontend
Design systemsAnimation & motionAccessibility (a11y)CSS & TailwindUI designUXDesign to codeshadcn/uiLanding pagesBest design skills
Most searched skills
find-skillscavemanfrontend-designbrainstormingsystematic-debuggingstop-slopemil-design-engui-ux-pro-maxkarpathy-guidelinesweb-design-guidelinesreact-best-practicesgrill-meimprovemicrosoft-foundryagent-browser
Browse all listings
All agent skillsAll MCP serversAll marketplacesAll plugins

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.