--- name: Test Plan Generator slug: test-plan-generator category: Quality description: Generates a targeted pre-merge test script that runs the most relevant unit, integration, Playwright, and Poshi tests based on branch changes, fitting within a 20-minute budget to catch likely regressions. github: "https://github.com/liferay/liferay-portal/tree/master/.claude/skills/test-plan" language: Java stars: 2260 forks: 3789 install: "git clone https://github.com/liferay/liferay-portal" added: 2026-07-20T06:48:19.520Z last_synced: 2026-07-29T06:36:54.445Z canonical_url: "https://dirskills.com/skills/test-plan-generator" --- # Test Plan Generator Generates a targeted pre-merge test script that runs the most relevant unit, integration, Playwright, and Poshi tests based on branch changes, fitting within a 20-minute budget to catch likely regressions. **Install:** `git clone https://github.com/liferay/liferay-portal` ## README # Test Plan Generator Produce a runnable shell script that executes the tests most likely to regress given the current branch's changes compared to master. The full test suite takes hours to run, so the team merges aggressively and relies on a daily full-suite run that delivers results within 24 hours of merge. This skill produces a focused premerge script (under 20 minutes) that mitigates risk without attempting full coverage — its goal is to catch the most likely regressions, not every possible one. ## How This Project Organizes Tests Consult the reference file for detailed test organization patterns: ``` ${CLAUDE_SKILL_DIR}/references/test-organization.md ``` ## Workflow ### Understand the Changes ```bash git diff master...HEAD --name-only git log master..HEAD --oneline ``` Read the changed files to understand what the changes actually do — not merely which files were touched, but what behavior changed. This understanding drives the test selection. ### Identify What Could Regress Consider the blast radius of each change: - **API or Interface Changes** (`portal-kernel`, `*-api` modules): Anything that depends on the changed API could regress. Search for consumers. - **Mechanical or Repetitive Changes** (e.g., adding a property across 200 files): The core logic test is essential. Also include a representative sample of end-to-end tests from affected modules to verify the mechanical change does not introduce regressions. - **Service Implementation Changes**: Tests for the service itself, along with tests for features that depend on it. - **Shared Infrastructure Changes** (e.g., a registry, a framework class, a base class): Every module that relies on that infrastructure could regress. Select representative tests spanning the affected modules. - **Web Layer Changes**: Playwright and Poshi tests for the affected UI. The objective is not to "find every test in modules that were touched" — it is to find tests that exercise the code paths that changed. ### Find the Tests For each area that could regress, search for test files. Use parallel Agent and Glob calls for speed. Consult `${CLAUDE_SKILL_DIR}/references/test-organization.md` for the exact patterns and conventions. **Verify every test file exists** before including it in the plan. ### Prioritize Within the 20-Minute Budget Apply the following priority order: **Always include:** 1. Unit tests for directly changed code — fast (approximately 5–15 seconds per class) and highest signal. 1. Integration tests that directly exercise the changed functionality. 1. Tests that exercise the core logic change end-to-end. **Include when budget allows:** 1. Representative integration tests from affected downstream modules — choose a few that cover distinct usage patterns rather than running them all. 1. Playwright tests for affected web modules (approximately 1–3 minutes per spec). **Include when still within budget:** 1. Poshi tests (approximately 2–5 minutes each). 1. Additional downstream module tests for broader coverage. When the change affects many modules (for example, a framework change), do not attempt to test every single module. Choose a diverse sample that covers different usage patterns of the changed code. ### Write the Script Delete any existing `test.sh` at the repository root, then write a new one. The script must be self-contained and runnable via `bash test.sh`. Use this structure: ```bash #!/usr/bin/env bash # # Test plan for branch: # Generated: # Estimated time: m / 20m budget # # Changes: commits, files changed # Affected areas: # set -o errexit set -o nounset set -o pipefail cd "$(dirname "${BASH_SOURCE[0]}")" _EXIT_CODE=0 exit ${_EXIT_CODE} ``` **Critical rules for the script:** - Replace `` with the actual commands discovered during selection. - Suffix every command with `|| _EXIT_CODE=1` so failures are recorded without halting execution. The `||` recovery neutralizes `errexit` on test failures while keeping the strict-mode block in place for unrecovered errors. The script exits with `${_EXIT_CODE}` at the end — `0` when all tests pass, `1` when any fail. - Use `./gradlew --project-dir ./modules` for Gradle tasks (the script's `cd` puts the repository root as the working directory). - Use `npx --prefix ./modules/test/playwright playwright test` for Playwright. - All test types (Unit, Integration, Playwright, Poshi) run directly — the portal is assumed to be running. - Precede each command with a single-line comment explaining why it was selected. State the rationale; do not restate the test name or module. After writing the script, mark it executable with `chmod +x test.sh` and instruct the user to run it via `./test.sh`. ## Guidelines - Verify every test file exists before adding it to the script. - When the changes are purely cosmetic (formatting, comments), say so and generate a script that exits `0` with a header explaining why.