Skill.md検索

何をテストすべきか（単体テストか統合テストか）を判断し、仕様の重要な分岐を壊れにくく保証するテストを設計・実装できます。 純粋ロジックには単体テスト、複数コンポーネントの連携や実API契約にはintegrationテストを使い分け、効率的にカバレッジ（テスト範囲）を確保します。 マルチテナント・ユーザー認可機能では「ユーザーAのデータをユーザーBが読めない」といった分離を必ず検証し、セキュリティリスクを防ぎます。 エラー条件も含めた成功系・失敗系テストを書き、404/401/403/422など主要なエラーパスも確認できます。 テスト名だけで仕様意図が分かる、保守性の高いテストコードを作成できます。 バックエンド開発者で、APIやロジックの信頼性を保ちたい人。 ウェブアプリケーション開発で、機能追加時に既存機能を壊していないか確認したい人。 テストを書いているが「何をテストすべきか」で迷っている開発者。 マルチテナント・ユーザー管理機能を実装する際に、データ分離やアクセス制御をテストで保証したい人。 「テストは緑にするためではなく、仕様の重要な分岐を壊れにくく保証するために書く」が基本。着手前に「何を保証したいか」「既にテスト済みか」「純粋ロジックか外部依存か」を整理する。単体テストは分岐・境界値細分化、外部API/DB不要、エラー条件を安価に再現する場合に選ぶ；統合テストはルーティング・DI・レスポンス整形まで通す、複数コンポーネント組み合わせ、API契約確認が必要な場合に選ぶ。単体テストは成功系・失敗系、境界値（limit-1,limit,limit+1,0）を意識し、依存はmock化；統合テストは1ファイル1機能領域、fixtureに後始末、yield/try-finally活用。ユーザー分離ある機能は「user A のデータをuser B が読めない」「更新・削除できない」「一覧に他人データ混ざらない」必須確認。完了条件：テスト名から仕様意図が分かる、fixtureが後始末持つ、重要分岐落としていない、変更コードに対応テスト追加・更新。

変更内容（diff）を自動で確認し、何が変わったかを把握した上で、次のステップを判断できます コミットメッセージを作成してコミットするだけでなく、適切なブランチ名を自動で提案・作成し、ブランチ管理を効率化できます ステージ対象ファイルを明示的に指定するため、意図しないファイルをコミットする事故を防ぎ、安全な変更管理ができます ブランチの作成からPRの作成まで一貫して処理され、手作業での入力ミスや手順漏れを排除できます PR本文に概要・変更内容・テスト方法が自動で記載されるため、レビュワーが内容を素早く理解できます Gitコマンドを何度も叩く手間を減らしたい開発者 PR作成時の手順を統一したいチーム コミットメッセージやブランチ名の規約を守り続けたいエンジニア 変更内容の把握からPR作成までを素早く済ませたい人

対話的にWebページを開いて操作し、その過程をスクリーンショットやビデオで記録できるため、動作確認を効率よく進められます クリック、テキスト入力、キー操作などを直感的にコマンドで実行し、ページの状態変化をリアルタイムで確認できます 複数の独立したセッションを同時に管理できるため、異なるユーザーシナリオを並行してテストできます 試行錯誤して確認したブラウザ操作を、そのままPlaywrightテストコードに変換し、再利用可能な自動テストに昇華できます トレーシングやネットワーク監視でデバッグ情報を取得し、複雑な操作フローの問題を追跡できます 手作業でWebアプリを操作して検証しているが、手順を自動化したいQA担当者 複雑なユーザーフローをPlaywrightで自動テスト化したい開発者 ブラウザの動作を動画やトレース情報として残したい人 テストコード作成前に、まずはCLIで対話的に仕様を確認したいエンジニア