메뉴
期待値(oracle)を用意しにくい対象を、入力全体に成り立つ性質やパラメータの組合せで 縛る生成テスト(プロパティベーステスト/PBT、コンビナトリアルテスト)を扱う。 test-catalog の手法カタログの一部。往復(round-trip)・不変条件・メタモルフィック関係 ・既知オラクル一致による性質の列挙、pairwise/t-way covering array による組合せ縮約を 検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
| name | generative-property |
| description | 期待値(oracle)を用意しにくい対象を、入力全体に成り立つ性質やパラメータの組合せで 縛る生成テスト(プロパティベーステスト/PBT、コンビナトリアルテスト)を扱う。 test-catalog の手法カタログの一部。往復(round-trip)・不変条件・メタモルフィック関係 ・既知オラクル一致による性質の列挙、pairwise/t-way covering array による組合せ縮約を 検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
入力を機械が生成する手法のうち、「どんな入力でも成り立つ関係(性質)」や「パラメータの組合せを小さな集合で覆うこと」で正しさを縛る系をまとめる。
頑健性(不正入力で壊れないこと)を叩くファジング系は generative-fuzzing.md に分けた。
古典のブラックボックス技法が「この入力でこの出力」を1つずつ固定するのに対し、ここでは入力例を列挙せず、入力全体に対する性質(PBT)か、パラメータ空間を覆うcovering array(コンビナトリアル)でまとめて縛る。 各項目は「概要」「目的/いつ使う」「TypeScript example」「落とし穴」「遂行手順(着手→完了)」「完了チェック(もれ確認)」「網羅設計での効かせ方」の構成で示す。
個別の入力例ではなく、入力全体に対して成り立つべき性質(不変条件)を宣言し、ライブラリが多数のランダム入力を生成して反例を探す。
「逆関数の往復で元に戻る」「可換」「結果は常にソート済み」のように、出力そのものより入力と出力の関係を言えるときに使う。 反例が見つかると自動で最小化(shrink)され、最小の壊れる入力が手に入る。 逆に成り立つ性質が「実装をそのまま書き写しただけ」になるなら oracle になっておらず、無価値なので使わない。
JSON エンコード/デコードの往復(round-trip)を性質として叩く。
import { describe, it, expect } from "vitest";
import fc from "fast-check";
import { encode, decode } from "./codec";
describe("codec: properties", () => {
it("round-trips any value (decode . encode = id)", () => {
fc.assert(
fc.property(fc.jsonValue(), (value) => {
expect(decode(encode(value))).toStrictEqual(value);
}),
{ numRuns: 1000, seed: 42 }, // 試行回数と seed を固定して再現可能にする
);
});
});
fc.jsonValue のように広い生成器を選ぶ。-0、+0、NaN、極小差の浮動小数を踏むので、toBe(Object.is)は -0 と +0 を別物と判定し、NaN === NaN は常に偽になる。数値の性質では === や許容誤差つき比較を選び、何を等価とみなすかを性質の一部として決める。手法が正しくても等価判定がずれると flaky に落ちる。PBT の本体は「対象を縛る性質を列挙し、各性質を反例の出る形のアサーションに落とす」ことだ。次の順で進める。
sort の結果は常に昇順、長さは入力と同じ。decode(encode(x)) === x、parse(format(x)) === x。エンコード/シリアライズ境界の定番。sort(reverse(xs)) と sort(xs) は等しい、abs(-x) === abs(x)。oracle が無い対象で特に効く。fc.integer()(負・0・極値を含む)、fc.jsonValue()、fc.string() など。狭い生成器(正の整数だけ等)は境界を踏まず穴を残す。前提条件があるなら fc.pre() か .filter() で絞る(絞りすぎると生成効率が落ちるので生成器側で形を作る方を優先)。-0/+0/NaN・浮動小数の扱いを toBe(Object.is)/===/許容誤差から選ぶ。オブジェクトは toStrictEqual。ここを決めないと手法が正しくても flaky に落ちる(落とし穴参照)。{ numRuns: N, seed: S } を明示し、打ち切り(何回試したら緑とみなすか)と再現性を確定させる。CI で回すなら numRuns を環境で上げ下げできるようにする。fc.examples か通常の例ベーステスト)に固定し、同じ入力で恒久的に縛る。shrink された最小例を捨てると次回ゼロから探索になる。grep -n "fc.assert" <test> の各ヒットに seed/numRuns 指定があるか。無ければ再現不能・打ち切り基準なし。fc.nat() のみ等)で済ませていないか。負・0・極値・空・巨大入力を踏む生成器になっているか目視する。PBT の網羅対象は「対象の正しさを縛る性質の集合」であり、入力例の集合ではない。
ゆえに網羅は「成り立つべき性質をすべて property 化し、各 property を十分広い生成器で多数試行して反例ゼロ」で定義する。
性質の列挙が網羅の上限を決めるので、手順1の4型で漏れなく挙げることが網羅の中核になる(挙げ損ねた性質は永遠にテストされない)。
生成器の広さが、列挙した性質を入力空間のどこまで踏ませるかを決める。狭い生成器は性質が正しくても境界の穴を残す。
例ベースの同値分割・境界値(blackbox-partition.md 系)と競合せず補完関係にある。例ベースで代表点を固定し、PBT で「その代表点の間も含めた全域で性質が保たれるか」を覆う。
配分の原則は、関係で言える正しさは PBT に寄せ、特定の入出力対応(回帰や仕様の具体例)は例ベースに残すことだ。
複数のパラメータが取り得る値の全組合せではなく、任意の t 個のパラメータの値の組合せを必ず一度は含む小さな集合(t-way / covering array)を自動生成する。
設定フラグ、対応環境、入力カテゴリなど独立パラメータが多く、全組合せが爆発するときに使う。 欠陥の多くは少数パラメータの相互作用で起きるという経験則により、2-way(pairwise)で大半を、3-way で更に深い相互作用を、現実的なケース数で押さえる。 パラメータ間に強い依存(ある値が別の値を無効化する)があるなら制約を入れずに使うと無効ケースを量産するので、制約対応の生成器が要る。
@fast-check/vitest などにある pairwise 生成を使い、3パラメータの 2-way 組合せを回す。
import { describe, it, expect } from "vitest";
import { pairwise } from "./pairwise"; // covering array を返す小関数 or ライブラリ
const os = ["linux", "mac", "win"] as const;
const node = ["18", "20", "22"] as const;
const mode = ["dev", "prod"] as const;
describe("build matrix: 2-way coverage", () => {
it.each(pairwise(os, node, mode))("builds on %s/node%s/%s", (o, n, m) => {
expect(build({ os: o, node: n, mode: m }).ok).toBe(true);
});
});
コンビナトリアルの本体は「パラメータ空間を定義し、無効組合せを制約で削り、covering array をツールに生成させる」ことだ。各ステップにツールと検証が紐づく。
blackbox-partition.md の同値分割)で代表値へ離散化する(例:タイムアウト → 0 / 正常 / 最大 / 超過)。軸の挙げ漏れはそのまま網羅の穴になる。if os=mac then node≠18 のような制約として列挙する。制約を入れないと無効ケースを量産し、build() がそもそも成立しないケースで赤になる。@fast-check/vitest の pairwise、allpairs、ACTS/PICT などの外部ツール出力を取り込む)で、制約を満たしつつ全 t-組合せを含む配列を生成させる。制約対応の生成器を使い、手順2の禁止組合せを入力する。it.each(...) に渡し、各行で対象を実行してアサートする。行ごとに独立して落ちる形にし、どの組合せで落ちたかが出力で分かるようにする(%s 埋め込み)。it.each に渡す配列がツール/関数の出力であることを確認する。コンビナトリアルの網羅対象は「t-way covering array が含むべき全 t-組合せ」であり、これを選んだ強さ t で完全に含むことが網羅基準になる。
全組合せ網羅は爆発するので、欠陥が少数パラメータの相互作用に集中するという経験則を使い、t を小さく(まず 2-way)取って現実的なケース数で相互作用を覆う。
パラメータと値域の列挙が網羅の母集合を決めるので、軸の洗い出しが網羅の中核になる(挙げ損ねた軸は covering array に入らず永遠に未テスト)。
制約は母集合から無効組合せを削るもので、網羅対象を「成立しうる組合せ」に限定する役割を持つ。
各軸の値域は連続値そのままではなく、同値分割で代表値へ離散化してから covering array に載せる。ここで blackbox-partition.md の同値分割・境界値と接続する(各軸内の網羅は同値分割、軸間の網羅はコンビナトリアル)。
配分の原則は、単一軸内の境界は境界値分析で厚く取り、軸をまたぐ相互作用はコンビナトリアルで t-way に覆うことだ。
不正・極端な入力を流し込んで頑健性(クラッシュ・例外・不変条件違反が起きないこと)を叩く手法(ファジング、カバレッジガイデッドファジング)は、generative-fuzzing.md にまとめた。
正解を直接持たないまま、別の参照や関係で正しさを判定する手法は、過去出力基準(スナップショット、承認テスト、仕様化テスト)を oracle-past-output.md、別実装基準(差分テスト)を oracle-differential.md、関係/モデル基準(メタモルフィックテスト、モデルベーステスト、形式検証連携)を oracle-relational.md にまとめた。
テストを書く道具としての LLM(AI/LLM 支援テスト生成)と、製品に組み込まれた非決定的出力そのものの検証(階層化品質設計)は、ai-nondeterministic.md にまとめた。