GitHub Copilotでテストコードを書くときの使い方

GitHub Copilotでテストコードを書くときは、期待する振る舞いと境界条件を人が先に決め、Copilotには既存のテスト環境に沿った実装を補助させます。テスト本数や通過率ではなく、「仕様の誤りを見つけるケースになっているか」で品質を判断してください。

Copilot Chatの /tests はテスト作成の出発点として利用できますが、コマンドや対象範囲はIDE、拡張機能、選択中のcontextで異なります。表示されない場合は通常のchatで対象と条件を明示すれば代替できます。生成テストをそのまま正解とみなさず、期待値、独立性、実行結果を確かめます。

仕様をテスト可能な形にする

まず対象のfunctionや画面で「どのinputに対し、何が返るか」を書きます。曖昧な要件をcodeから推測させると、既存実装の誤りを正解として固定するtestができます。APIならstatusとbody、formなら表示と送信の変化、計算ならinput・output・丸め方まで具体化します。

正常系だけでなく、input境界、異常系、権限、順序、時間依存を検討します。全部が必要とは限りません。仕様とriskに沿って選び、関係ない組み合わせを大量に作らないことも大切です。空文字を拒否するfunctionなら通常文字列、空文字、空白だけ、nullを受ける契約があるかを分けます。型上nullがあり得ないなら、そのtestは不要です。

生成前にケース表を作る

表は横にスクロールできます

ケース	入力 / 状態	期待結果	防ぐ問題
正常	有効な値	成功結果	基本動作の回帰
境界	最小・最大	契約どおり受理または拒否	off-by-one
不正	型・形式が違う	明確なerror	暗黙変換
空・欠損	空値・未指定	仕様に従う	欠損時の誤動作
依存失敗	API / DBが失敗	安全な失敗応答	例外漏れ

各行が実際の仕様にあるか確認してください。すべてのfunctionにDBやAPIがあるわけではなく、ないcaseを機械的に追加するとnoiseや過剰mockを生みます。決済や権限のような高risk領域では、拒否条件や副作用を明示します。

/testsへ渡すcontext

GitHub公式Docsは、IDE内Copilot Chatから /tests を使うテスト生成方法を案内しています。選択したcodeだけでなく、期待動作、使っているtest framework、命名規則、禁止変更を添えます。例：「次のケース表を既存Vitestで実装。production codeは変更しない。mockは外部境界だけ。追加後に対象testを実行し、失敗は原因を説明」。IDEや拡張の違いでcommandが使えないときは、同じ内容を通常promptへ移します。

関連typeや既存testもcontextに加えます。必要な前提が分からないなら、先に調査または質問させます。slash commandの有無を理由にtest設計を省略しません。

実装と期待値を独立させる

既存実装から期待値を写すだけだと、実装中の誤りをtestが追認します。testの根拠は仕様、利用者が観測する振る舞い、独立した計算例に置きます。内部関数の呼び出し順は、外部から重要な契約でない限り固定しすぎないようにします。

税込額を計算する例なら、実装式ではなく丸め規則を要件から決め、手計算できる値で期待値を定めます。button送信なら内部handler名でなく、利用者から見える結果やerror表示を確認します。期待値を仕様から決められないときは、testを増やす前に要件を明確にします。

生成結果のreview

• 条件表のどの行を検証しているか

• 期待値は実装でなく仕様や独立例から決まっているか

• assertionが部分一致、空配列、未定義に甘くないか

• mockは必要な外部境界に限られているか

• test名と失敗内容が条件を説明するか

• 重複caseや到達しない分岐がないか

• skip、timeout延長、assertion弱化で通していないか

fixtureやmock dataが実際の形式と制約に合うかも見ます。既存helperを使うなら、どの副作用を隠すか把握します。スナップショットだけに頼ると、変更理由が分からないまま大きな出力差を受け入れることがあります。

実行して失敗を分類する

変更前に通っていたtestと今回の対象testを分けて実行します。Copilotがcommandを提案したら、READMEやpackage設定に存在するものか確認します。実行結果がなければ「実行済み」としません。

表は横にスクロールできます

失敗	可能性	次の確認
期待値不一致	仕様理解または期待値の誤り	ケース表に戻る
setup error	test環境や依存不足	既存setupを確認
flaky	時刻、並列、外部依存	固定clockや隔離を検討
既存suite失敗	今回変更との因果不明	変更前結果と比較
新testだけ失敗	testかproduction behavior	要件とcaseを再確認

testを通すために意味を弱めず、失敗名、実出力、期待値根拠を渡して局所修正します。再実行後もtest差分を見直します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  GitHub Copilot

  公式サイトを見るTool詳細を見る

危険なテストを見分ける

壊れた実装を守るtestに注意します。内部呼び出し順を過剰固定する、依存をすべてmockして統合境界を一度も通さない、例外を捕まえて確認しない、広いsnapshot一つに頼る、といった形です。一方、外部serviceを実際に呼ぶ必要はありません。契約境界でfakeを使うなら、失敗応答、遅延、重複送信など実際のriskを検証します。

E2Eが必要な場合は、credentialや本番dataを含めない環境で行い、外部通信を含む検証をunit testと区別します。短時間でtestを増やすより、重要な失敗を一つ再現できるtestを作る方が役立つことがあります。

30秒で見るチェック

時間が限られるreviewでは、利用者が失敗すると困るbehaviorと今回のriskを一つずつ確認します。正常系と最も重要なfailure caseがあるか、期待値が独立しているか、実行commandが分かるかを見ます。網羅率だけを上げるより、欠けている危険な条件を明らかにします。

AIものさしの判断

GitHub Copilotのテスト生成は、定型コードやboilerplateを減らす補助として有効です。しかし、何を保証し、どのfailureを優先し、期待値を何から決めるかは人が定めます。生成数でなく仕様との対応と失敗検出力を基準にしてください。

実務では仕様をケース表へ落とし、Copilotに既存frameworkで実装させ、実行結果とtest差分をreviewします。/testsが使えない環境でも流れは同じです。testが通っても要求や期待値が正しいとは限らないため、最後に利用者の期待へ戻って確認します。

具体例：入力検証のテスト設計

例えば商品名を保存する関数なら、要件を「空文字と空白だけは拒否、前後の空白はtrim、上限は80文字、正常値は保存」と定めます。このとき少なくとも通常値、前後に空白がある値、空文字、空白のみ、ちょうど80文字、81文字をケース候補にできます。nullは型や外部入力契約で到達可能なら加え、型上受け取らないなら含めません。

期待結果も具体化します。拒否時に保存関数が呼ばれないこと、trim後の値を保存すること、上限を超えた場合に既定errorを返すことなどです。ただし「内部関数が1回呼ばれる」を仕様が求めていないなら固定しません。Copilotにはこの条件表から既存frameworkのtestへ変換させ、期待値と追加caseの理由も説明させます。

生成テストの範囲を決める

対象fileのunit testだけでよいか、UIからの振る舞いを確認するintegration testが必要かは、リスクと契約境界で決めます。単純なformat関数ならunit testで足りるかもしれません。保存後の表示や権限による拒否が重要なら、呼び出し境界を通すtestが必要です。全層を一つのend-to-end testにまとめると失敗原因が見えにくくなるので、testの役割を分けます。

テスト名は「should work」のような曖昧な表現より、条件と期待を示します。例として「空白だけの名前は保存せずvalidation errorを返す」のように書けば、失敗時に要件を読み直す手間が減ります。

ケース表の優先順位は、利用者への影響と見逃しやすさで決めます。正常系が一つ通っても、重要な拒否条件や副作用を確かめないまま「十分にテストした」とは言えません。ケースを足す理由と、今回は扱わない条件を短く残せば、網羅率を追うだけの追加を避けられます。testが重くなる場合は、速いunit testで主要な境界を確認し、integration testでは外部との接続点を代表する条件に絞ります。

作成後は変更差分も確認します。意図しない補助変更がないか見ます。

商品名入力の例なら、unit testではvalidation結果とtrim後の値、integration testでは保存境界で副作用がないこと、E2Eでは画面のerror表示と成功後の状態を確かめます。三層すべてを作るのではなく、今回変えた契約を直接検証できる層を選びます。