Skip to content
cccskills
FreePublished on GitHub

poshi-shrink

Plan and carry out a reduction of a Liferay component’s Poshi test suite by identifying overlapping tests and combining their unique assertions. The skill inventories matching test files, preserves tests with special setup or properties, and commits each planned rename or merge separately.

OriginalShow the original description

Shrink a Liferay component's Poshi test suite by merging overlapping tests. Use when the user asks to reduce, merge, or clean up Poshi tests for a @component-name.

liferay/liferay-portal2,267 stars(GitHub 2,267 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Reduce overlapping Poshi tests for a component
  • Prepare a test suite for migration to another test layer
  • Review a file-by-file plan for merging functional tests

Files included (1)

  • SKILL.md5.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Shrink Poshi Tests

A playbook for shrinking a Liferay component's Poshi test suite before migrating tests to Playwright, Java integration, or the unit layer. Typical outcome: a file with ~27 tests ends up with ~8, in ~24 small reviewable commits.

Preconditions

  • The working tree is clean. Abort and ask the user to commit or stash first when dirty.

Input

Component Name

The @component-name annotation, passed as ${ARGUMENTS} (e.g., portal-analytics-cloud, portal-commerce, portal-content-management). When ${ARGUMENTS} is empty, scan .testcase files under portal-web/test/functional/com/liferay/portalweb/tests/enduser, list the distinct @component-name values found, and ask the user to pick one. Do not guess.

Verify the component by enumerating, under portal-web/test/functional/com/liferay/portalweb/tests/enduser, every .testcase whose @component-name matches; abort when no file matches. The same enumeration feeds the Shrink Plan: per file, capture the path, the testray.main.component.name value, and the test-block count.

Expected Output

Shrink Plan

Build the plan via plan mode (EnterPlanMode) using this format:

## Inventory

| File | Test Count | testray.main.component.name |
| --- | --- | --- |
| <path> | <N> | <component> |

## Files to Attack

### <file path> (N → M)

> **Group A — <Context name>** (N → 1):
>
> - Rename `<Keeper>` → `<FinalName>` (commit 1)
> - Merge `<Source2>` → adds `<assertion>` (commit 2)
> - Merge `<Source3>` → adds `<assertion>` (commit 3)
> - … etc

### <next file path> (N → M)

…

Sort the inventory ascending by test count so small files (easy wins) surface first. Avoid files with 40+ tests on the first pass.

Pick the keeper for each group: the test with the most comprehensive assertions, even when its name is awkward — the keeper does not have to keep its name. The final name describes the combined behavior (e.g., ContentPerformancePanelInBlogDisplayPage, LanguageDropdownInContentPage) and is typically different from the keeper's original name.

Common merge-worthy signals — classic patterns from Liferay test names:

  • Multiple AuthorNotShowIn<Context> tests — usually one per panel context is enough.
  • Multiple MetricsIconVisibleIn<Context> + PanelInformationIn<Context> — the first checks title+traffic, the second title+URL+language — huge overlap between the two.
  • CheckAllInfo* or similar catch-all tests that duplicate specific-field tests.
  • Tests that share the full setUp + first N tasks (navigate, create blog, open panel) and differ only in the final assertion.

Merge Signals — DO

  • Same setup + same UI surface + different assertion → one test with N assertion tasks.
  • Tests differing only in asset type (blog vs document vs widget vs content page) when the panel behavior being asserted is identical — one representative usually suffices; propose deletion for the rest rather than merging four tests into four.
  • Tests where the source's assertion is already fully covered in the target — the commit still happens — it just deletes the source.

Merge Signals — DO NOT

  • Tests with test-level property overrides that differ: property portal.upstream = "quarantine", property test.liferay.virtual.instance = "false", property test.run.type = "single" (when not inherited).
  • Tests with special setup (localized URLs, fragment translations, system settings changes, extra page creation).
  • Tests with @ignore / @skip annotations.

Shrunk Test Files

After ExitPlanMode returns the user's approval, apply each operation in the order it appears in the plan and commit after each one — one commit per operation, never squashed. The per-merge granularity is exactly what makes the diff reviewable.

  • Rename — change the keeper's test <OldName> to test <FinalName> with no other edits. Commit message: <TICKET> Rename test <Keeper> to <FinalName>.
  • Merge — delete the source's test <Source> { ... } block and fold its unique assertions into the target as new task blocks. When the source's assertions are already fully covered by the target, simply delete the source. When the same condition is asserted at different strengths (e.g., AssertTextEquals.assertPartialText("web/<site-path>") vs the weaker AssertVisible value1="http://"), keep the stronger one. Commit message: <TICKET> Merge test <Source> into <FinalName>.

When the file convention keeps tests alphabetical, add a final <TICKET> Alphabetic order commit after all merges.

Summary

After the file is shrunk, report:

  • The file shrunk and its testray.main.component.name.
  • Before/after test counts.
  • Total commits made (renames + merges + optional cleanups).
  • Tests kept intact and the reason (special setup, differing properties, @ignore).

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

format-source

FreeSummary

Use this skill to format Liferay source files according to the project’s conventions. It describes the formatter workflows for modules and committed changes, how to handle Go and shell files, and which generated files to leave untouched.

  • Formatting source files in a module
  • Checking formatting across committed changes
  • Applying the separate Go or shell formatting rules
liferay/liferay-portal2.3KUpdated Oct 29, 2026

jira-bug

FreeSummary

Use this skill to file a bug in the LPD Jira project from a description or fix commit. It gathers reproduction steps and expected versus actual behavior, applies required project fields, and returns the created ticket key and link.

  • Filing a newly reported LPD bug
  • Turning a fix commit into a bug ticket
  • Recording reproduction steps and expected behavior
liferay/liferay-portal2.3KUpdated Oct 29, 2026

jira-task

FreeSummary

Use this skill to create a Task ticket in the LPD Jira project from a description or commit. It gathers missing details, selects a matching component, formats the description with acceptance criteria when applicable, and returns the ticket key and link.

  • Creating an LPD task from a short description
  • Turning a commit into a task ticket
  • Adding acceptance criteria to a Jira task
liferay/liferay-portal2.3KUpdated Oct 29, 2026

markdown-format

FreeSummary

Format Markdown files for Liferay repositories by aligning front matter, heading capitalization, shell examples, and prose with the project’s style rules. Use it to clean up or copy-edit a document and receive a summary of the changes.

  • Formatting a Markdown guide for a Liferay repository
  • Cleaning up headings and front matter in a document
  • Polishing shell examples and prose in Markdown
liferay/liferay-portal2.3KUpdated Oct 29, 2026

poshi-migrate

FreeSummary

Analyzes a Liferay Poshi `.testcase`, checks feasibility and existing coverage, then routes each test to Playwright, Jest, JUnit unit, or Java integration tests. It creates a migration plan and can implement the approved changes using repository patterns.

  • Migrating Poshi test cases to modern test layers
  • Finding existing specs that already cover Poshi tests
  • Planning Playwright, Jest, or JUnit test conversions
liferay/liferay-portal2.3KUpdated Oct 29, 2026

pr

FreeSummary

Create a GitHub pull request from the current branch, assemble its title and description from the branch’s commits, and connect it to the relevant Jira tickets. The workflow also runs the required PR check and records the new PR URL on each ticket.

  • Opening a pull request for the current development branch
  • Preparing a PR description from commits and Jira tickets
  • Recording a new PR on its related Jira work items
liferay/liferay-portal2.3KUpdated Oct 29, 2026

See all skills by liferay

Report a problem with this skill