Back to .md Directory

Agent Instructions: Execute TESTME.md Tests

Defines a Markdown-based test specification format and instructs an AI agent to discover, parse, and execute those tests in a codebase.

May 2, 2026
0 downloads
4 views
ai agent
View source

What this file does

Defines a Markdown-based test specification format and instructs an AI agent to discover, parse, and execute those tests in a codebase.

When to use it

  • You want AI agents to run human-readable test specs without a test framework
  • You need a portable test convention that works across any project or language
  • You are building tooling that lets non-developers write executable tests in Markdown
  • You want to automate end-to-end UI tests with step-by-step natural language instructions

Agent Instructions: Execute TESTME.md Tests

You are tasked with finding and executing TESTME.md test specifications in this codebase.

What is TESTME.md?

TESTME.md is a convention for writing human-readable test specifications that AI agents can execute. Tests are written in plain Markdown with clear steps and expectations.

Project: https://github.com/evilsocket/testme.md Specification: https://github.com/evilsocket/testme.md/blob/main/SPECS.md

Your Task

  1. Find all TESTME.md files in the codebase
  2. Parse each file according to the specification
  3. Execute the tests following the steps described
  4. Report results clearly

Discovery

Search for test files in this order:

  1. TESTME.md in repository root
  2. TESTME.md in tests/, test/, e2e/, spec/ directories
  3. Any *.testme.md files recursively

Execution Flow

For each TESTME.md file found:

1. Read and parse the file
2. Verify Prerequisites (abort if any fail)
3. Execute Setup steps in order
4. Run each Test:
   - Perform the steps
   - Verify expectations
   - Record pass/fail
5. Execute Teardown steps
6. Report results

File Structure

A TESTME.md file contains these sections:

SectionRequiredPurpose
HeaderYesSuite name and description
PrerequisitesNoSystem requirements to verify
SetupNoEnvironment preparation steps
EnvironmentNoVariables and configuration
TestsYesTest cases with steps and expectations
TeardownNoCleanup steps

Interpreting Steps

Step PhraseAction
"Go to /path"Navigate to the URL
"Navigate to /path"Navigate to the URL
"Click [button/link]"Find and click the element
"Enter [value]"Type into the focused or specified input
"Fill [field] with [value]"Enter value in the named field
"Wait for [element/condition]"Wait until condition is met
"Select [option]"Choose from dropdown/select
"(any unique value)"Generate a unique value (use timestamp)
"from VAR env var"Read from environment variable

Interpreting Expectations

ExpectationVerification
"is visible"Element exists and is displayed
"is not visible"Element hidden or not present
"URL contains X"Current URL includes the string
"URL changes to X"Navigation occurred to that path
"shows [text]"Element contains the text
"error message appears"Error UI is displayed

Handling Ambiguity

When steps are unclear:

  1. Make reasonable assumptions based on context
  2. Use common UI patterns (submit buttons, form fields, etc.)
  3. Document any assumptions in your report
  4. If truly blocked, note it and continue to next test

Result Reporting

Report results in this format:

TESTME Results: [Suite Name]
=====================================
File: [path/to/TESTME.md]

Prerequisites: PASSED (or FAILED with details)
Setup: PASSED (or FAILED with details)

Tests:
  PASS: [Test Name]
  PASS: [Test Name]
  FAIL: [Test Name]
        Step: [Which step failed]
        Expected: [What was expected]
        Actual: [What happened]

Teardown: PASSED (or SKIPPED)

Summary: X tests, Y passed, Z failed
=====================================

Error Handling

ScenarioAction
Prerequisite failsReport failure, skip this file
Setup failsReport failure, run teardown, skip tests
Test step failsRecord failure, continue to next test
Assertion failsRecord failure, continue to next test
Teardown failsLog warning, complete report

Environment Variables

If an Environment section exists, use the specified defaults when variables are not set:

## Environment

| Variable | Default | Description |
|----------|---------|-------------|
| BASE_URL | http://localhost:3000 | App URL |
| ADMIN_EMAIL | admin@example.com | Admin account |

Use http://localhost:3000 if BASE_URL is not set.

Begin

Find all TESTME.md files in this codebase and execute them now. Report results for each file found.

What's inside

8 sections (header, prerequisites, setup, environment, tests, teardown, step interpretations, expectation interpretations) plus execution flow and error handling rules

Change this for your project

  • Replace http://localhost:3000 with your application's default base URL
  • Replace admin@example.com with your own default admin email
  • Replace evilsocket/testme.md with your own repository name and specification URL

Where it goes

Keep in docs/ or alongside the feature. Agents read it to implement against a defined contract.

Worth borrowing

  • Mapping natural language step phrases (e.g. 'Click [button]') to concrete actions makes specs readable by humans and executable by agents
  • A required 'Tests' section with optional prerequisites, setup, and teardown mirrors standard test lifecycle patterns

Related Documents