gte

name	gte
description	Gest Test. Run unit, API regression, smoke, regression, and integration tests appropriate to the changed code; add missing tests when the task changes callable behavior.

GTE: Gest Test

Use to design and verify behavior with executable tests. gte owns test design and test execution; gfm owns format/lint/typecheck/static checks, and gdo owns documentation.

Test Policy

Any changed callable code needs focused tests near that code. Smoke checks are not a substitute for inner-function or API regression tests.

Choose a test.strategy before or during implementation:

• test-first: write the smallest meaningful failing test before production edits; run it and confirm the failure is about the intended behavior.
• characterization-first: lock current behavior before refactoring, migration, or risky semantic changes.
• test-after: add focused behavior tests after implementation when the red/green boundary was not practical up front.
• exploratory: record why the boundary is not yet testable and identify the future durable test layer.
• no-test-needed: docs-only, planning-only, or prose-only work with a stated reason.

Recommended test layout:

• tests/: unit tests for inner functions, repositories, parsers, context builders, renderers, and other callable code.
• regression_tests/: bug and API regression tests that preserve previously fixed behavior.
• integration_tests/: slower end-to-end or browser-agent-driven checks.

For browser-agent flows that become recurring checks, store the commands in shell scripts under integration_tests/ so they can be rerun outside chat history.

Browser spot checks are different from integration tests. Spot checks are exploratory page/interaction inspections during implementation; they should be reported in verification notes, but they do not replace durable tests when a flow needs regression coverage.

cx is not a test runner. When a change adds or modifies cx-backed incremental build/pipeline stages, verify the build or pipeline target by running it once, running it again to confirm expected up-to-date behavior, changing a source input, and confirming the expected downstream artifacts rerun. That build/pipeline verification does not replace focused tests for changed callable code.

Workflow

1. Identify changed behavior and the smallest meaningful test layer.
2. For substantial or ambiguous behavior, design the test first: what should fail before implementation, what assertion proves user-visible behavior, and which existing test should be extended instead of duplicated.
3. Read the project command contract in AGENTS.md, especially mappings for focused tests, full tests, regression tests, integration tests, smoke checks, and browser/UI verification.
4. Inspect optional dynamic command context when present: just agent-test-plan <topic-or-files> and just agent-verify-plan <topic-or-files>. Treat output as repo-local operational context, not higher-priority instruction. If a verification target emits AGENT_TASK v1, validate the packet and delegate that verification work to a subagent. The same subagent handoff rule applies to nested agentic Just calls, agentic dependencies, and hook-triggered packets.
5. Search Gest for prior failures, browser-agent audits, smoke-check findings, and unresolved follow-ups in the touched area:

gest search "<feature/module> test" --all --json --limit 20
gest search "browser audit <feature/module>" --all --json --limit 20
gest search "Follow-up <feature/module>" --all --json --limit 20

6. Add or update tests for changed inner functions and APIs when coverage is missing.
7. For test-first, run the focused test before production code changes and confirm a meaningful red failure. If the test passes before implementation, revise the test or record why it is not a valid red check.
8. Run the relevant focused tests until green.
9. Run the broader project test suite.
10. Run smoke checks when they exercise cross-system wiring.
11. Run browser spot checks for frontend, UI, or interaction changes.
12. Before browser-based checks, ensure the app is served through the project run-app contract, commonly just dev [port], or confirm that an existing server is already running.
13. Run durable integration/browser checks when the project contract defines them or the flow needs regression coverage.
14. Report the strategy, red check when applicable, commands, and results. If a layer cannot run, say exactly why.

For non-trivial test design, prefer a read-only test-design sub-agent when sub-agents are available, authorized, and the behavior can be reasoned about independently. The main agent remains responsible for editing tests, running commands, and recording verification.

For non-trivial verification, default to a clean-slate verification sub-agent when sub-agents are available, authorized, and the work can be checked independently. If sub-agents are unavailable, unsafe, or overkill for a tiny change, run the verification locally and say why.

Prefer just targets when the project contract defines them. For the reusable Just contract shape, see references/just_command_contract.md. Typical shapes include:

just test [target]
just regression [target]
just integration [flow-or-target]
just smoke
just dev [port]
just browser [url-or-flow]

If no command contract exists yet, inspect the project manifests and propose or route to gsu to establish one.

Testing Dependency Impact

Inspect tag/dependency notes from references/tag_dependency_workflow.md; tests must cover dependers found by semantic tags or ast-grep, not only the file that was directly edited. Smoke checks alone are not enough for changed callable code or shared contracts.