Conducty TDD

Conducty TDD — Test-Driven Development for Orchestrated Agents

TDD in Conducty operates at two levels: the orchestrator writes the "test" (verification command + acceptance criteria) before writing the prompt, and the implementer follows red-green-refactor within each prompt. Both levels follow the same discipline: define what success looks like before doing the work.

The Two Levels

Level 1: Orchestrator TDD (Plan Time)

The orchestrator (you, during [[conducty-plan]]) writes the verification step FIRST for every prompt. This is the test. If you can't write a concrete verification command, the acceptance criteria aren't clear enough — fix them before generating the prompt.

Define verification → Write prompt → Execute → Verify → Learn

This maps directly to red-green-refactor:

• Red: The verification command would fail right now (feature doesn't exist yet)
• Green: After execution, the verification command passes
• Refactor: In [[conducty-improve]], refine the prompt template based on what worked

If you can't write the verification step, you don't understand what you're building. Go back to [[conducty-shape]].

Level 2: Implementer TDD (Execution Time)

The implementer subagent follows classical red-green-refactor within each prompt:

1. RED — Write one minimal test that describes the desired behavior. Run it (Bash). Watch it fail.
2. Verify RED — Confirm it fails because the feature is missing, not because of a typo or import error.
3. GREEN — Write the simplest code that makes the test pass. Nothing more.
4. Verify GREEN — Run the test. Confirm it passes. Run all tests. Confirm no regressions.
5. REFACTOR — Clean up: remove duplication, improve names, extract helpers. Keep tests green.
6. Repeat — Next behavior, next test.

How They Connect

The orchestrator's verification step is the acceptance test. The implementer's TDD cycle produces unit tests. When the implementer finishes, the orchestrator runs the verification command (via [[conducty-verify]]) to confirm the acceptance test passes. Both levels must be green.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

This applies to implementers. If code was written before its test, delete the code and start over. Not "adapt it," not "keep it as reference" — delete it and write the test first.

At the orchestrator level: no prompt without a verification step. If the verification field is empty, the prompt is not ready.

Good Tests

Test behavior, not implementation. A test that breaks when you refactor (without changing behavior) is testing the wrong thing. Tests should survive restructuring.

One test, one behavior. If the test name contains "and," split it. Each test should have exactly one reason to fail.

Real code over mocks. Use mocks only when external dependencies force it (network, database, third-party APIs). Mocking your own code means the code is too coupled — fix the coupling.

Names describe the behavior. rejects empty email tells you what broke. test_email_3 tells you nothing.

Failure messages diagnose the problem. A good assertion message tells you what happened and what was expected without reading the test code.