決済サービスに単体テストを追加する
決済処理向けのテスト作成プレイブックを構築し、Devin に課金フロー、返金ロジック、Webhook ハンドラーを包括的な単体テストでカバーさせましょう。決済向けのテストプレイブックを作成する
A playbook は、チームのテスト方針や慣習を定義しておくことで、Devin がエンジニアと同じ流儀でテストを書けるようにするものです。決済コードには、冪等性、通貨の精度、ゲートウェイのリトライ、PCI 準拠の安全なモックなど、特有の考慮事項があります。そのため、決済に特化した playbook であれば、汎用的な playbook では見逃してしまう問題も洗い出せます。オプション 1: 自分で playbook を作成する。 Settings > Playbooks > Create playbook に移動し、以下のように基準を定義します:オプション 2: Advanced Devin に playbook の作成を任せる。 テストの作法や規約を説明すると、Advanced Devin が完全な playbook を生成します:その後、チームのスタイルを示す具体例として、既存の最良のテストファイル(例:
src/services/__tests__/UserService.test.ts)を Knowledge のエントリとして追加し、Devin が参照できるようにします。未テストの決済コードを特定する
特定のファイルをDevinに指定する前に、まず決済モジュールのどこにカバレッジの抜け漏れがあるかを把握しましょう。Devinにカバレッジツールを実行させて、最も問題の大きい箇所を洗い出します:Devinはターミナルでテストスイートを実行し、カバレッジレポートを解析して、優先度順のリストを返します。
Devin に PaymentService のテストを作成させる
新しいセッションを開始し、決済テスト用プレイブックを添付します(添付されると、接続済みを示す青いピル状の表示が出ます)。そのうえで、どのモジュールをカバーするかを Devin に指示します:Devin はモジュールを読み込み、既存のテストを確認してパターンを把握し、あなたのプレイブックに従った網羅的なテストファイルを作成して実行します。Devin は説明欄にテストファイルとカバレッジのサマリーを記載した PR を作成します。
残りの決済モジュールに取り組んでください
最初のPRをレビューします。モックの戦略やアサーションのスタイルがしっくりこない場合は、他のモジュールでプレイブックを実行する前に更新してください。最初の1回でフィードバックを反映しておけば、同じ問題を複数のPRで繰り返し修正せずに済みます。次に、ギャップリストを上から順に埋めていきます。より速く進めるには、Advanced Devin を使って支払いモジュールごとに並列セッションを立ち上げ、いずれも同じプレイブックに従わせます。または、週次セッションをスケジュールしておき、カバレッジのしきい値を下回った支払いモジュールを検出して、自動的にテストを書かせることもできます。
