Skip to main content

GitHub Copilot での社内のテスト カバレッジの拡大

機能を理解し、開発者を支援し、Copilot の効果を測定します。

この機能を使用できるユーザーについて

GitHub Copilot Business or GitHub Copilot Enterprise

このガイドは、エンジニアリング システムの改善を推進するための戦略とメトリックを推奨する GitHub の「Engineering System Success Playbook (エンジニアリング システム サクセス プレイブック)」(ESSP) からヒントを得ています。

Copilot のロールアウトを開始する場合は、目標を定義し、それに応じてロールアウトを計画し、スタッフに目標を明確に伝えることをお勧めします。 「GitHub Copilot を使って会社のエンジニアリング目標を達成する」をご覧ください。

1.成功への障壁を特定する

ESSP が推奨する最初の手順は、会社の改善を妨げている障害を明確に理解することです。 現在のベースライン、目的とする将来の状態、進歩を妨げる障壁を理解することで、的を絞った効果的な変更を行うことができます。

多くのソフトウェア チームは、単体テストのカバレッジが狭いために、高品質なコードを維持する上で根深い課題に直面しています。 ペースの速い開発環境で、特にチームが機能を迅速に提供するように迫られている場合、テストの作成は時間がかかる作業であり、必要ではないと見なされることがよくあります。

その結果、重大なバグが開発ライフサイクルの終盤に (多くの場合、ステージング環境または運用環境で) 検出されることがあります。

これは一連の悪影響につながります。

  • バグ率の上昇と顧客から報告される issue
  • 配置後のバグ修正にかかるコストの増加
  • コードの安定性に対する開発者の自信の低下
  • 事後対応型のデバッグとパッチ適用によるリリース サイクルの遅延

レガシ システムでは、依存関係が複雑であったり、コードの文書化が不十分だったりするため、テスト カバレッジの対応がさらに困難になる可能性があります。 開発者は、以前のコードベースやテスト フレームワーク全般に精通していない可能性があり、それによって問題がさらに複雑になります。

テスト カバレッジの向上は推奨されるベスト プラクティスですが、多くのチームはそのための時間と専門知識を確保するのに苦労しています。

2.オプションを評価する

次の手順は、手順 1 で特定した障壁に対処するための解決策を評価し、同意することです。 このガイドでは、GitHub Copilot で特定した目標に与える影響に焦点を当てます。 新しいツールの導入を成功させるには、カルチャやプロセスの変更も必要であることに留意してください。

パイロット グループで新しいツールとプロセスの試験を実施し、フィードバックを収集して成功を測定します。 試用版で使うトレーニング リソースとメトリックについては、「3. 変更を実装する」と「監視するメトリック」セクションを参照してください。

Copilot にサインアップする

Copilot の活用方法

GitHub Copilot を使うと、単体テストの作成プロセスを大幅に高速化し、簡素化できます。 周囲のコードとコンテキストを理解することで、テスト対象のコードの構造とロジックに合うテスト関数の提案を Copilot から受けることができます。

Copilot の機能は、さまざまなシナリオで役立ちます。

  • 開発者が新しい関数を作成するときに、Copilot から対応するテスト ケースの提案をインラインで自動的に受けることができます。
  • レガシ コードをリファクタリングする場合、Copilot を使うと、回帰を防ぐためのテスト スキャフォールディングを生成できます。
  • テストされていないモジュールの場合、開発者は、テスト カバレッジが欠落しているか一貫性がない場合でも、意味のあるテスト ケースを生成するように Copilot に依頼できます。

Copilot を使うと、単体テストはより簡単に、高速に、かつ手動操作が減り、テスト カバレッジのギャップにつながる摩擦を軽減し、チームが品質第一の考え方を採用できるようになります。

ユース ケース

  • インライン テスト生成: 開発者は、コンテキストを切り替えることなく、特定の関数またはモジュールのテストを生成するように Copilot に依頼できます。
  • エッジ ケース カバレッジの向上: エッジ シナリオ (null の入力、空のリスト、無効な状態など) に対して Copilot にプロンプトを指定することで、開発者はより多くのロジックのブランチをすばやくカバーできます。
  • オンボードの高速化: 新しいチーム メンバーが Copilot を使うと、生成されたテスト ケースを確認して、関数がどのように動作するかを理解できます。
  • CI/CD に関する支援: Copilot は、テストをビルド パイプラインに統合する方法について提案し、カバレッジの向上が品質ゲートの達成に直接つながるように支援します。

文化に関する考慮事項

GitHub Copilot のロールアウトに加えて、目標を達成できない可能性のある社会的または文化的要因にも対処する必要があります。

次の例は、ESSP の "アンチパターン" に関するセクションから抜粋したものです。

  • チームは、手動テストや不十分な自動テストに依存している可能性があります。 これは、自動化のためのリソース制約や、最新のテスト ツールの経験不足が原因である可能性があります。
  • チームがリリースを長く待ちすぎると、大量のコードを一度に配置することになり、バグや回帰の検出が難しくなります。 これは、CI/CD パイプラインの成熟度の欠如、厳格なコンプライアンス要件、または PR と配置間のレビュー サイクルが長いことが原因で発生する可能性があります。

3.変更を実装する

障害を克服するための適切なアプローチを特定したら、特定したソリューションを拡大します。 新しいツールやプロセスのロールアウトを成功させるには、ロールアウトの各部分に所有権を割り当て、目標について率直にコミュニケーションを取り、効果的なトレーニングを提供し、成果を測定することが重要です。

このセクションでは、開発者向けのシナリオ例、ベスト プラクティス、リソースについて説明します。 このセクションを使って、従業員が目標に沿った方法で Copilot を使用できるように、コミュニケーションとトレーニング セッションを計画することをお勧めします。

インラインでテストを生成する

  1. VS Code でテストする関数を選び、Copilot にプロンプトを入力します: Generate a unit test for this code.
  2. Copilot により、言語と構造に応じて、インラインまたは別のテスト ファイルにテストが生成されます。
  3. 提案をレビューし、改善し、受け入れます。

エッジ ケースをカバーする

  1. テストを作成した後、Copilot に質問します: What are some edge cases I should test for this function?

    または: Write test cases for when the input is null or empty.

  2. Copilot により、境界条件をカバーするための追加のテスト ケースが提案されます。

  3. テストをレビューし、テスト スイートに組み込みます。

新しいコードを理解する

  1. レガシ関数を選び、Copilot に質問します: Explain what this function does and generate a test to validate it.
  2. Copilot により、関数の目的が説明され、対応するテスト ケースが提案されます。
  3. テスト ケースを確認して、想定される動作を理解し、コンテキストをすばやく構築します。

CI/CD に関する支援を受ける

  1. テスト ケースをレビューし、コードベースにコミットします。
  2. Copilot に質問します: Where should I place this test if I want it to run in CI?
  3. Copilot により、コードベースの構造に基づいて、テスト ファイルを配置する場所とパイプライン構成を更新する方法が提案されます。

開発者向けのベスト プラクティス

開発者に推奨されること:

  • Copilot とチャットするときに、わかりやすいコメントやプロンプトを使う。 例: Generate unit tests for a function that calculates discounts based on user type and purchase amount.
  • Copilot を使ってロジックのカバレッジを確認する 例: What branches or conditions does this function have that should be tested?
  • さまざまなプロンプト手法について確認し、さまざまな AI モデルの結果を比較する。

開発者に推奨されないこと:

  • ロジックをレビューせずに生成されたテストを受け入れる。 テストが実際の要件を反映し、現実的な入力と出力を処理していることを確認する。
  • エッジ動作のアサートをスキップする。 "正常系のパス" のみをテストすると、回帰を見逃すおそれがあります。
  • 文書化されていないビジネス ルールを推測するために Copilot に頼る。 プロンプトやコメントで常にコンテキストを提供してください。
  • 人間によるコード レビューの代わりとして Copilot を扱う。 Copilot を使うとこのプロセスは加速されますが、エンジニアリングの判断の適用は依然として必要です。

開発者用リソース

注目すべきメトリック

新しいツールの試用版を評価し、完全なロールアウトによって一貫した改善が実現されていることを確認するには、結果を監視し、必要に応じて調整を行う必要があります。 一般に、品質、速度、開発者の満足度という主要なゾーンを考慮し、これらのゾーンがどのように連携してビジネス成果に貢献するかを検討することをお勧めします。

この特定の目標に対する Copilot の影響を評価するために、検討することをお勧めするメトリックをいくつか示します。

  • テスト カバレッジ: Copilot の導入後の行とブランチのカバレッジの増加を追跡します。 可能であれば、CI パイプラインからのテスト カバレッジ レポートを確認します。
  • 配置後のバグ率: 運用環境で報告されるバグは少なくなるはずです。
  • 開発者の自信: アンケートや振り返りを使って、開発者が新しいコードをリリースする際にどの程度自信を持っているかを評価します。
  • テストの作成時間: 単体テストの作成にかかる時間の短縮を測定します。