Catalogskills.sh · amplicode

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?").

Review advisedVerified hub264 installs

Savant verdict: Review advised

Security analysis or source-hub review identified patterns requiring attention.

Live evaluation

Not evaluated yet. Workspaces can request a live evaluation.

Security assessment

Scan pending.

Structure

  • No license declaredConfirm you may reuse this skill before importing it into your repository.
  • The source hub's security checks flagged this skillGen Agent Trust Hub: warn (The skill manages Gradle test execution through the IDE or console. It contains potential security risks including command injection vulnerabilities in the shell fallback path and XML External Entity (XXE) vulnerabilities in the test result parsing script.)

SKILL.md

---
name: run-tests
description: >-
  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?").
---

# 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.