# Run Tests

> Run a Gradle project's tests by test type or module — unit, integration, or all. Use this skill whenever the user wants to run, re-run, or check the project's tests (e.g. "run the unit tests", "run all tests", "run the integration tests for the vet module", "did the tests pass?").

- Skill: `amplicode/run-tests` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add amplicode/run-tests`
- Raw SKILL.md: https://api.skillmd.com/api/skills/amplicode/run-tests/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: amplicode (https://skillmd.com/u/amplicode)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/amplicode/run-tests

---


# Run tests

## Test types and modules

Test **types** (extend as a project needs):

| Type | Meaning | Typical Gradle tasks |
|------|---------|----------------------|
| `unit` | fast tests, no Spring/Docker | `test` |
| `integration` | Spring + Testcontainers | `testIntgr` or `integrationTest` |
| `all` | everything | `test` + `testIntgr` |

A **module** is a Gradle subproject; prefix its path onto the task
(`:web:test`). A module combines with a type on the fly — build that
configuration when first asked and remember it.

## Pick the path

Probe FIRST, here, before loading either reference — so you read only the one you
need. Call `steroid_list_projects` (via ToolSearch if the tool schema isn't
loaded):

- It returns the repo you're in → **IDE path**: note that entry's `project_name`
  and follow `references/ide.md` (runs tests inside the IDE, each in its own Run
  tab). Its steps start already knowing the `project_name` — don't re-probe.
- It fails, or the repo isn't listed → **console Gradle path**: follow
  `references/gradle.md` (runs Gradle in the console) and tell the user you used
  the console fallback because the IDE wasn't reachable.

Both paths end by collecting the result **in a Haiku subagent** that returns the
`references/report.md` report and nothing else — keeping the long test/build
output out of the main context. Act on that report in the main model.

