Test-Driven Development with Hermes Agent: RED-GREEN-REFACTOR

Test-Driven Development (TDD) is a discipline where you write a failing test before any production code, then write the minimal code to pass it, and finally refactor. This skill, bundled with Hermes Agent, enforces the RED-GREEN-REFACTOR cycle and the iron law: no production code without a failing test first. Reach for it when you need to build new features, fix bugs, refactor, or change behavior with high confidence and low regression risk.

What it does

TDD turns the development process into a tight feedback loop. You start by writing one test that defines the desired behavior. You run it and watch it fail (RED). Then you write the simplest code that makes that test pass (GREEN). Finally, you clean up the code without changing its behavior (REFACTOR). The skill enforces this cycle strictly, with no shortcuts. It also provides a verification checklist, common rationalizations to avoid, and integration patterns for Hermes Agent's terminal and delegate_task tools.

Before you start

• Prerequisites: A Python environment with pytest installed. The skill assumes you are working in a project that already has a tests/ directory and a pytest configuration.
• Permissions: You need write access to the project files and permission to run terminal commands.
• Platform limits: The skill works on Linux, macOS, and Windows. The terminal tool must be available.
• Related skills: This skill pairs with systematic-debugging, plan, and subagent-driven-development. You may want to use plan first to outline the work, then apply TDD during implementation.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

If you write code before the test, delete it and start over. No exceptions. Do not keep it as reference, do not adapt it while writing tests, do not look at it. Delete means delete. Implement fresh from tests.

RED: Write a Failing Test

Write one minimal test that shows what the code should do. The test must be clear, test real behavior, and cover one thing.

Good test:

def test_retries_failed_operations_3_times():
    attempts = 0
    def operation():
        nonlocal attempts
        attempts += 1
        if attempts < 3:
            raise Exception('fail')
        return 'success'

    result = retry_operation(operation)

    assert result == 'success'
    assert attempts == 3

Clear name, tests real behavior, one thing.

Bad test:

def test_retry_works():
    mock = MagicMock()
    mock.side_effect = [Exception(), Exception(), 'success']
    result = retry_operation(mock)
    assert result == 'success'  # What about retry count? Timing?

Vague name, tests mock not real code.

Requirements:

• One behavior per test
• Clear descriptive name (if you find yourself using "and" in the name, split it)
• Real code, not mocks (unless truly unavoidable)
• Name describes behavior, not implementation

Verify RED: Watch It Fail

MANDATORY. Never skip.

# Use terminal tool to run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

Confirm:

• Test fails (not errors from typos)
• Failure message is expected
• Fails because the feature is missing

If the test passes immediately, you are testing existing behavior. Fix the test. If the test errors, fix the error and re-run until it fails correctly.

GREEN: Write Minimal Code

Write the simplest code to pass the test. Nothing more.

Good:

def add(a, b):
    return a + b  # Nothing extra

Bad:

def add(a, b):
    result = a + b
    logging.info(f"Adding {a} + {b} = {result}")  # Extra!
    return result

Do not add features, refactor other code, or "improve" beyond the test. Cheating is OK in GREEN: hardcode return values, copy-paste, duplicate code, skip edge cases. You will fix it in REFACTOR.

Verify GREEN: Watch It Pass

MANDATORY.

# Run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

# Then run ALL tests to check for regressions
pytest tests/ -q

Confirm:

• Test passes
• Other tests still pass
• Output pristine (no errors, warnings)

If the test fails, fix the code, not the test. If other tests fail, fix regressions now.

REFACTOR: Clean Up

After green only:

• Remove duplication
• Improve names
• Extract helpers
• Simplify expressions

Keep tests green throughout. Do not add behavior. If tests fail during refactor, undo immediately and take smaller steps.

Repeat

Next failing test for next behavior. One cycle at a time.

Avoid Horizontal Slices

Do not write all tests first and then all implementation. That is horizontal slicing: RED becomes "write a pile of imagined tests" and GREEN becomes "make the pile pass." It produces brittle tests because the tests are designed before the implementation has taught you what behavior and interface actually matter.

Use vertical tracer bullets instead:

WRONG:
  RED:   test1, test2, test3, test4
  GREEN: impl1, impl2, impl3, impl4

RIGHT:
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

A tracer bullet is one end-to-end behavior slice. It proves the path works, teaches you about the interface, and keeps each next test grounded in what you just learned.

Why Order Matters

"I'll write tests after to verify it works"

Tests written after code pass immediately. Passing immediately proves nothing:

• Might test the wrong thing
• Might test implementation, not behavior
• Might miss edge cases you forgot
• You never saw it catch the bug

Test-first forces you to see the test fail, proving it actually tests something.

"I already manually tested all the edge cases"

Manual testing is ad-hoc. You think you tested everything but:

• No record of what you tested
• Can't re-run when code changes
• Easy to forget cases under pressure
• "It worked when I tried it" ≠ comprehensive

Automated tests are systematic. They run the same way every time.

"Deleting X hours of work is wasteful"

Sunk cost fallacy. The time is already gone. Your choice now:

• Delete and rewrite with TDD (high confidence)
• Keep it and add tests after (low confidence, likely bugs)

The "waste" is keeping code you can't trust.

"TDD is dogmatic, being pragmatic means adapting"

TDD IS pragmatic:

• Finds bugs before commit (faster than debugging after)
• Prevents regressions (tests catch breaks immediately)
• Documents behavior (tests show how to use code)
• Enables refactoring (change freely, tests catch breaks)

"Pragmatic" shortcuts = debugging in production = slower.

"Tests after achieve the same goals, it's spirit not ritual"

No. Tests-after answer "What does this do?" Tests-first answer "What should this do?"

Tests-after are biased by your implementation. You test what you built, not what's required. Tests-first force edge case discovery before implementing.

Common Rationalizations

Excuse	Reality
"Too simple to test"	Simple code breaks. Test takes 30 seconds.
"I'll test after"	Tests passing immediately prove nothing.
"Tests after achieve same goals"	Tests-after = "what does this do?" Tests-first = "what should this do?"
"Already manually tested"	Ad-hoc ≠ systematic. No record, can't re-run.
"Deleting X hours is wasteful"	Sunk cost fallacy. Keeping unverified code is technical debt.
"Keep as reference, write tests first"	You'll adapt it. That's testing after. Delete means delete.
"Need to explore first"	Fine. Throw away exploration, start with TDD.
"Test hard = design unclear"	Listen to the test. Hard to test = hard to use.
"TDD will slow me down"	TDD faster than debugging. Pragmatic = test-first.
"Manual test faster"	Manual doesn't prove edge cases. You'll re-test every change.
"Existing code has no tests"	You're improving it. Add tests for the code you touch.

Red Flags, STOP and Start Over

If you catch yourself doing any of these, delete the code and restart with TDD:

• Code before test
• Test after implementation
• Test passes immediately on first run
• Can't explain why test failed
• Tests added "later"
• Rationalizing "just this once"
• "I already manually tested it"
• "Tests after achieve the same purpose"
• "Keep as reference" or "adapt existing code"
• "Already spent X hours, deleting is wasteful"
• "TDD is dogmatic, I'm being pragmatic"
• "This is different because..."

All of these mean: Delete code. Start over with TDD.

Verification Checklist

Before marking work complete:

• Every new function/method has a test
• Watched each test fail before implementing
• Each test failed for expected reason (feature missing, not typo)
• Wrote minimal code to pass each test
• All tests pass
• Output pristine (no errors, warnings)
• Tests use real code (mocks only if unavoidable)
• Edge cases and errors covered

Can't check all boxes? You skipped TDD. Start over.

When Stuck

Problem	Solution
Don't know how to test	Write the wished-for API. Write the assertion first. Ask the user.
Test too complicated	Design too complicated. Simplify the interface.
Must mock everything	Code too coupled. Use dependency injection.
Test setup huge	Extract helpers. Still complex? Simplify the design.

Hermes Agent Integration

Running Tests

Use the terminal tool to run tests at each step:

# RED — verify failure
terminal("pytest tests/test_feature.py::test_name -v")

# GREEN — verify pass
terminal("pytest tests/test_feature.py::test_name -v")

# Full suite — verify no regressions
terminal("pytest tests/ -q")

With delegate_task

When dispatching subagents for implementation, enforce TDD in the goal:

delegate_task(
    goal="Implement [feature] using strict TDD",
    context="""
    Follow test-driven-development skill:
    1. Write failing test FIRST
    2. Run test to verify it fails
    3. Write minimal code to pass
    4. Run test to verify it passes
    5. Refactor if needed
    6. Commit

    Project test command: pytest tests/ -q
    Project structure: [describe relevant files]
    """,
    toolsets=['terminal', 'file']
)

With systematic-debugging

Bug found? Write failing test reproducing it. Follow TDD cycle. The test proves the fix and prevents regression.

Never fix bugs without a test.

Testing Anti-Patterns

• Testing mock behavior instead of real behavior, mocks should verify interactions, not replace the system under test
• Testing implementation details, test behavior/results, not internal method calls
• Happy path only, always test edge cases, errors, and boundaries
• Brittle tests, tests should verify behavior, not structure; refactoring shouldn't break them

Final Rule

Production code → test exists and failed first
Otherwise → not TDD

No exceptions without the user's explicit permission.

When not to use it

Ask the user first before skipping TDD for:

• Throwaway prototypes
• Generated code
• Configuration files

If you find yourself thinking "skip TDD just this once," stop. That is rationalization.

Limits and gotchas

• The skill is strict. If you violate the letter of the rules, you violate the spirit. There are no exceptions without explicit user permission.
• The RED phase requires that you watch the test fail. If you skip this, you cannot know if the test tests the right thing.
• The GREEN phase forbids adding any code beyond what is needed to pass the test. No logging, no extra features, no refactoring.
• The REFACTOR phase must keep tests green. If a test breaks, undo immediately.
• Horizontal slicing (writing all tests first, then all implementation) is explicitly forbidden. Use vertical tracer bullets instead.

What pairs with this

• systematic-debugging: When you find a bug, write a failing test that reproduces it, then follow the TDD cycle. Never fix a bug without a test.
• plan: Use the plan skill to outline the work before starting TDD.
• subagent-driven-development: When dispatching subagents, enforce TDD in the goal using the delegate_task pattern shown above.