Run any Skill in Manus with one click

Get Started

test-scripts-and-infrastructure

Stars38

Forks4

UpdatedMarch 18, 2026 at 06:18

how to structure and write tests (shell) scripts involving infrastructure

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

humansintheloop-dev

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	test-scripts-and-infrastructure
description	how to structure and write tests (shell) scripts involving infrastructure

IMPORTANT:

NEVER WRITE SHELL scripts that directly test Java applications ** Java applications should ALWAYS be directly tested using JUnit Tests executed by Gradle. ** NEVER write shells script that use gradlew bootrun. ** NEVER write shell scripts like this: test-scripts/test-health.sh that starts the application, waits for startup, curls /actuator/health, and asserts HTTP 200 with status UP

Shell scripts are for testing infrastructure such a docker, docker compose, kubernetes etc.

When writing tests for shell scripts or infrastructure:

Tests MUST execute the script and verify the observable outcome
Tests MUST NOT use grep/static analysis to check file contents
Tests MUST NOT check for file existence as a proxy for correctness
Before writing a test, state: "The observable outcome is: [X]"
If a test can pass without running the code, it's not a behavioral test
ALWAYS put the test scripts in a test-scripts/ subdirectory
If necessary, create a test-scripts/test-cleanup.sh script that cleans up test state, e.g. removes docker containers
Write test-xyz.sh scripts for specific behaviors, e.g. test-init-ca.sh tests init-ca.sh
ALWAYS Incrementally create a test-end-to-end.sh script that first runs test-cleanup.sh and then runs each test-xyz.sh script in sequence
CI workflows should call ./test-scripts/test-end-to-end.sh, not individual test scripts
When adding new test scripts, add them to test-end-to-end.sh rather than modifying CI configuration

More from this repository

same repository

debugging-ci-failures

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

Guidelines for watching CI builds and diagnosing failures. Claude should use this skill when watching a CI build or investigating why a CI build failed.

2026-07-1738

plan-file-management

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

Structural CRUD and reordering operations on plan files via the `i2code plan` CLI — insert/replace/delete/reorder threads and tasks, mark tasks/steps complete or incomplete, fix numbering, and query plan structure (get-next-task, get-thread, get-summary, list-threads). Claude MUST use this skill (not raw file edits) for any change to a plan file's threads, tasks, or steps, and for reading plan structure programmatically.

2026-06-2438

apply-design-patterns

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

Consult the design pattern catalog before implementing or refactoring code.

2026-04-2938

test-output-to-logfile

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

When running test scripts or long-running commands that produce verbose output, redirect output to a log file under logs/ to avoid truncation in the Bash tool. Claude should use this skill when running test scripts, end-to-end tests, or any command likely to produce large output. NOTE: This skill does not apply to Gradle because test output is written to TEST*.xml files.

2026-04-2938

test-runner-java-gradle

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

a definition of tests and testing in a Java project using Gradle and JUnit 5. Advice on using Gradle to run tests.

2026-04-2938

ask-a-friend

humansintheloop-dev/humansintheloop-dev-workflow-and-tools

When stuck on a problem, formulate a well-structured question and copy it to the clipboard for pasting into ChatGPT. Claude should use this skill when debugging efforts stall or when an outside perspective would help.

2026-03-1838

name	test-scripts-and-infrastructure
description	how to structure and write tests (shell) scripts involving infrastructure

IMPORTANT:

NEVER WRITE SHELL scripts that directly test Java applications ** Java applications should ALWAYS be directly tested using JUnit Tests executed by Gradle. ** NEVER write shells script that use gradlew bootrun. ** NEVER write shell scripts like this: test-scripts/test-health.sh that starts the application, waits for startup, curls /actuator/health, and asserts HTTP 200 with status UP

Shell scripts are for testing infrastructure such a docker, docker compose, kubernetes etc.

When writing tests for shell scripts or infrastructure:

Tests MUST execute the script and verify the observable outcome
Tests MUST NOT use grep/static analysis to check file contents
Tests MUST NOT check for file existence as a proxy for correctness
Before writing a test, state: "The observable outcome is: [X]"
If a test can pass without running the code, it's not a behavioral test
ALWAYS put the test scripts in a test-scripts/ subdirectory
If necessary, create a test-scripts/test-cleanup.sh script that cleans up test state, e.g. removes docker containers
Write test-xyz.sh scripts for specific behaviors, e.g. test-init-ca.sh tests init-ca.sh
ALWAYS Incrementally create a test-end-to-end.sh script that first runs test-cleanup.sh and then runs each test-xyz.sh script in sequence
CI workflows should call ./test-scripts/test-end-to-end.sh, not individual test scripts
When adding new test scripts, add them to test-end-to-end.sh rather than modifying CI configuration