本文へ移動
cccskills
無料GitHub で公開日本語紹介

poshi-shrink

LiferayコンポーネントのPoshiテストを調べ、重複するテストを統合・整理する計画を立ててから、確認しやすい単位でテスト数を減らします。

原文原文の説明を見る

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)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • コンポーネントのPoshiテストを減らしたいとき
  • Playwright移行前にテストを整理したいとき
  • 重複テストの統合計画を確認したいとき

日本語での紹介

できること

指定された @component-name に一致するPoshiの .testcase を列挙し、ファイルごとのテスト数や testray.main.component.name を整理した縮小計画を作ります。セットアップと画面が同じでアサーションだけ異なるテストなど、統合候補を見つけ、残すテストと統合後の名前、追加する確認内容を示します。特別なセットアップ、異なるプロパティ、@ignore や @skip があるテストは対象から外します。利用者の計画承認後、テスト名の変更や統合を操作ごとにコミットし、変更の確認単位を保ちます。

こんなときに便利

Playwright、Java統合テスト、ユニットテスト層への移行前に、既存のPoshiテストを整理したいときに使えます。アセット種別だけが異なるテストや、同じ確認を重ねているテストを見直し、必要なアサーションを残してテスト数を減らす計画を立てられます。

使い方の例

  • 「portal-commerceのPoshiテストを整理する計画を作って」
  • 「このコンポーネントの重複テストを統合して」

注意点

作業開始時にGitの作業ツリーがクリーンである必要があります。対象コンポーネントを特定できない場合は候補を示して選択を求めます。ファイル変更とコミットは計画への承認後に行います。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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 のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

format-source

無料概要あり

Liferayのソースコードを対象に、対応する整形ツールとルールを使って形式をそろえ、生成ファイルを避けながら修正対象を確認できます。

  • モジュールのソースを整形したいとき
  • コミット済み変更の書式を確認したいとき
  • Goやシェルの整形ルールを適用したいとき
liferay/liferay-portal2,2672026年10月29日 更新

jira-bug

無料概要あり

不具合の説明や修正コミットから必要事項を整理し、再現手順や期待・実際の動作を含むバグチケットをLPDプロジェクトのJiraに登録できます。

  • LPDの不具合をJiraに登録したいとき
  • 修正コミットからバグを起票したいとき
  • 再現手順と期待動作を整理したいとき
liferay/liferay-portal2,2672026年10月29日 更新

jira-task

無料概要あり

説明やコミット内容をもとに、必要な情報を整えてLPDプロジェクトのJiraにタスクを登録し、チケット番号と閲覧URLを受け取れます。

  • LPDの作業タスクを起票したいとき
  • コミットからタスクを整理したいとき
  • 受け入れ条件付きで課題を登録したいとき
liferay/liferay-portal2,2672026年10月29日 更新

markdown-format

無料概要あり

Liferay向けのMarkdown文書を、前付けの順序や見出しの表記、シェル記法、文章の調子まで整え、リポジトリの規約に沿った読みやすい形に仕上げます。

  • Liferay向けMarkdownを整えたいとき
  • 見出しや前付けを規約に合わせたいとき
  • シェル例と文章を校正したいとき
liferay/liferay-portal2,2672026年10月29日 更新

poshi-migrate

無料概要あり

LiferayのPoshi `.testcase` を内容に応じてPlaywright、Jest、JUnit、Java統合テストへ移行し、既存テストとの重複や移行を妨げる条件も整理します。

  • Poshiテストを新しいテスト層へ移したいとき
  • 既存Playwrightテストとの重複を調べたいとき
  • 移行先と実装手順を計画したいとき
liferay/liferay-portal2,2672026年10月29日 更新

pr

無料概要あり

現在のブランチからGitHubのPRを作成し、関連するJiraチケットをレビュー状態に移してPRのURLを記録する手順を進めます。

  • 現在のブランチからPRを作りたいとき
  • コミット内容をPR本文にまとめたいとき
  • JiraチケットにPRを記録したいとき
liferay/liferay-portal2,2672026年10月29日 更新

liferay のスキルをすべて見る

このスキルの問題を報告する