Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

test-scripts-and-infrastructure

Estrelas38

Forks4

Atualizado18 de março de 2026 às 06:18

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

humansintheloop-dev

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

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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

Mais deste repositório

mesmo repositório

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