Academy → Using HermesOfficial documentation · clear explanation

Test Driven Development — TDD: enforce RED-GREEN-REFACTOR, tests before code

Test Driven Development — TDD: enforce RED-GREEN-REFACTOR, tests before code

Intermediate12 minutes3 questions2026-08-09
The idea in one minute

Start with meaning, then move to detail.

This lesson explains Test Driven Development — TDD: enforce RED-GREEN-REFACTOR, tests before code as part of extending Hermes and connecting external tools. You will learn what it does, when it matters, and the smallest safe test that proves it works.

If you are new

If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?

For hands-on use

For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.

For specialists

For advanced readers, inspect Skill metadata, Reference: full SKILL.md, Overview, then verify failure modes and version compatibility.

What do you need first?

Complete installation and one successful task before adding new capabilities.

What will you know?

A clear outcome before you read.

  • Understand Test Driven Development — TDD: enforce RED-GREEN-REFACTOR, tests before code without assumed prior knowledge.
  • Separate the source description from what still needs testing in your environment.
  • Read the first command and identify its inputs and outputs before copying it.
Lesson terms

Short definitions before the details.

Skill
An instruction bundle that teaches Hermes a repeatable workflow without necessarily adding an external service.
Official page description

TDD: enforce RED-GREEN-REFACTOR, tests before code

Topic map

What does the source say, and in what order?

  1. 01
    Skill metadata

    Start here to understand the core idea or structure.

  2. 02
    Reference: full SKILL.md

    Read this after the foundation, then connect it to the previous step.

  3. 03
    Overview

    Read this after the foundation, then connect it to the previous step.

  4. 04
    When to Use

    Read this after the foundation, then connect it to the previous step.

  5. 05
    The Iron Law

    Read this after the foundation, then connect it to the previous step.

  6. 06
    Red-Green-Refactor Cycle

    Read this after the foundation, then connect it to the previous step.

  7. 07
    RED — Write Failing Test

    Read this after the foundation, then connect it to the previous step.

  8. 08
    Verify RED — Watch It Fail

    Read this after the foundation, then connect it to the previous step.

  9. 09
    GREEN — Minimal Code

    Read this after the foundation, then connect it to the previous step.

  10. 10
    Verify GREEN — Watch It Pass

    Finish here to verify the result and special cases.

Examples from the official page

Copy only after you understand the effect.

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Clear name, tests real behavior, one thing. **Bad test:**
Vague name, tests mock not real code. **Requirements:** - One behavior per test - Clear descriptive name ("and" in name? Split it) - Real code, not mocks (unless truly unavoidable) - Name describes behavior, not implementation ### Verify RED — Watch It Fail **MANDATORY. Never skip.**
Try it now

Read the first command and identify its inputs and outputs before copying it.

Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.

Knowledge check

Three decisions before completion.

1. What is the source of truth when “Test Driven Development — TDD: enforce RED-GREEN-REFACTOR, tests before code” changes?
2. What is the best way to apply this lesson?
3. What should happen before a step can modify files or an external account?