Liferayのソースコードを対象に、対応する整形ツールとルールを使って形式をそろえ、生成ファイルを避けながら修正対象を確認できます。
- モジュールのソースを整形したいとき
- コミット済み変更の書式を確認したいとき
- Goやシェルの整形ルールを適用したいとき
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.
実行スコア 未検証
インストール方法を見る指定された @component-name に一致するPoshiの .testcase を列挙し、ファイルごとのテスト数や testray.main.component.name を整理した縮小計画を作ります。セットアップと画面が同じでアサーションだけ異なるテストなど、統合候補を見つけ、残すテストと統合後の名前、追加する確認内容を示します。特別なセットアップ、異なるプロパティ、@ignore や @skip があるテストは対象から外します。利用者の計画承認後、テスト名の変更や統合を操作ごとにコミットし、変更の確認単位を保ちます。
Playwright、Java統合テスト、ユニットテスト層への移行前に、既存のPoshiテストを整理したいときに使えます。アセット種別だけが異なるテストや、同じ確認を重ねているテストを見直し、必要なアサーションを残してテスト数を減らす計画を立てられます。
作業開始時にGitの作業ツリーがクリーンである必要があります。対象コンポーネントを特定できない場合は候補を示して選択を求めます。ファイル変更とコミットは計画への承認後に行います。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
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.
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:
AuthorNotShowIn<Context> tests — usually one per panel context is enough.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.setUp + first N tasks (navigate, create blog, open panel) and differ only in the final assertion.property portal.upstream = "quarantine", property test.liferay.virtual.instance = "false", property test.run.type = "single" (when not inherited).@ignore / @skip annotations.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.
test <OldName> to test <FinalName> with no other edits. Commit message: <TICKET> Rename test <Keeper> to <FinalName>.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.
After the file is shrunk, report:
testray.main.component.name.@ignore).まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Liferayのソースコードを対象に、対応する整形ツールとルールを使って形式をそろえ、生成ファイルを避けながら修正対象を確認できます。
不具合の説明や修正コミットから必要事項を整理し、再現手順や期待・実際の動作を含むバグチケットをLPDプロジェクトのJiraに登録できます。
説明やコミット内容をもとに、必要な情報を整えてLPDプロジェクトのJiraにタスクを登録し、チケット番号と閲覧URLを受け取れます。
Liferay向けのMarkdown文書を、前付けの順序や見出しの表記、シェル記法、文章の調子まで整え、リポジトリの規約に沿った読みやすい形に仕上げます。
LiferayのPoshi `.testcase` を内容に応じてPlaywright、Jest、JUnit、Java統合テストへ移行し、既存テストとの重複や移行を妨げる条件も整理します。
現在のブランチからGitHubのPRを作成し、関連するJiraチケットをレビュー状態に移してPRのURLを記録する手順を進めます。