implement-unit-testing-script

Implement Unit Testing Script

This skill produces a single executable script that runs the unit tests for a generated build folder, following a consistent, language-agnostic pattern.

The reference implementation is assets/run_unittests_java.sh. Read it first — every script you produce must be a faithful translation of that pattern into the target language's tooling and the user's shell environment. There are also Windows PowerShell equivalents of these scripts in assets/run_unittests_*.ps1.

Pick the Shell First

Before writing anything, decide which shell flavor the script must target — it depends on the user's environment, not on the language:

• Bash (.sh) — macOS, Linux, WSL, CI runners on Linux. Default unless the user is on native Windows.
• PowerShell (.ps1) — native Windows / PowerShell-only environments.

If you can't tell from the project (no obvious OS hints, no existing scripts), ask the user.

The same seven-step pattern applies to both. Only the syntax changes.

The Pattern

Every testing script must implement these steps in this order:

1. Toolchain check. Verify that the required language runtime / build tool (and the required version, if any) is installed. If not, print an error and exit with code 69.
2. Argument validation. Require exactly one positional argument: the source build folder. If missing, print usage and exit with code 1. The renderer passes this argument as an absolute path (older renderer versions passed a relative one) — the script must work with both, which is why the working-folder name in step 3 is built from the argument's basename, never from the raw argument.
3. Working directory setup. Define a working folder in the system temp directory: /tmp/<lang>_$(basename "$1") in Bash, Join-Path ([System.IO.Path]::GetTempPath()) "<lang>_$(Split-Path $BuildFolder -Leaf)" in PowerShell (written as <temp>/<lang>_<basename> below). If it exists, wipe its contents; otherwise create it. Register cleanup so the folder is removed when the script exits — trap 'rm -rf "$WORKING_FOLDER"' EXIT in Bash, a Remove-Item -Recurse -Force in the finally block in PowerShell. This folder — and only this folder — is where every subsequent write must land.
4. Copy the build. Recursively copy everything from the source folder into the working folder. After this step the source folder ($1) is treated as read-only for the rest of the script.
5. Enter the working directory. cd / Set-Location into <temp>/<lang>_<basename>. If that fails, exit with code 2. All remaining steps run from inside the working folder; they must never write back to the source build folder.
6. Install dependencies into an isolated environment inside <temp>/<lang>_<basename>. Set up a per-working-folder dependency location (a Python venv at ./.venv, a local ./node_modules, a project-scoped Maven repo at ./.m2, etc.) and install/resolve all dependencies into it. Never install into the source build folder, the user's global cache (~/.m2, system-wide pip, ~/.cargo, ~/.npm, ...), or anywhere outside <temp>/<lang>_<basename>. If the install command fails, propagate its exit code immediately and do not proceed to step 7. See Dependency isolation for per-language specifics.
7. Run the tests. Invoke the language's standard test command (e.g. mvn test, pytest, npm test, go test ./..., cargo test), pointed at the same isolated environment from step 6. The script's final exit code is whatever the test command returns.