跳到正文
cccskills
免费在 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.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

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-portal星标 2,267(GitHub 2,267 + cccskills 0)

实测评分 未实测

查看安装方法

适用场景

  • 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

包含的文件(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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).

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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-portal22672026年10月29日 更新

jira-bug

免费

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-portal22672026年10月29日 更新

jira-task

免费

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-portal22672026年10月29日 更新

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-portal22672026年10月29日 更新

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-portal22672026年10月29日 更新

pr

免费

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-portal22672026年10月29日 更新

查看 liferay 的全部技能

报告此技能的问题