変更要約: Professional Cloud Developer 第3章を新規作成（ドメイン2「ビルドとテスト」: 開発環境＝CLI エミュレータ/ユニットテスト・Cloud Shell/Cloud Workstations・Cloud Code・Gemini Code/Cloud Assist、ビルドとテスト＝Cloud Build/Artifact Registry・Binary Authorization(プロベナンス)・ユニット/統合テストの CI 自動化）。
3.2ビルドとテスト（CI）
Cloud Build によるソースからのコンテナビルド、Artifact Registry への保存、Binary Authorization による出所（プロベナンス）の保証、ユニット/統合テストの自動実行、そして CI パイプラインに組み込んだ継続的な検証を理解します。
コードをソースから安全に・繰り返し成果物へ変え、テストで品質を担保します。CI（継続的インテグレーション）が開発の中核です。
3.2.1ビルドと成果物の保存
Cloud Build はソースコードから コンテナイメージをビルドし、Artifact Registry（コンテナ/パッケージのレジストリ）に保存します。サプライチェーンの安全のために、Binary Authorization で署名・検証（プロベナンス＝出所の保証）を構成し、信頼できる成果物だけをデプロイ許可します。「ソースからビルド＝Cloud Build」「成果物の保存＝Artifact Registry」「出所の保証＝Binary Authorization」と結びます。
3.2.2テストの自動化
テストは段階で行います：個々の関数/クラスを検証する ユニットテスト（ローカルやエミュレータで高速）、複数コンポーネントの連携を検証する 統合テスト（Cloud Build のステップで自動実行）。これらを CI パイプライン に組み込み、変更ごとに自動で検証することで、欠陥を早期に・安全に見つけます。AI コーディングアシスタントでテスト作成を支援することもできます。「変更ごとの自動検証＝CI に組み込む」「連携の検証＝統合テスト」を押さえます。
「要件 → 手段」が頻出。例：「ソースからコンテナをビルド」＝Cloud Build、「ビルドしたイメージを保存」＝Artifact Registry、「信頼できる成果物だけデプロイ」＝Binary Authorization（プロベナンス）、「変更ごとに統合テストを自動実行」＝Cloud Build のステップ（CI）。
混同に注意：
①Cloud Build（ビルド/CI）と Artifact Registry（保存）は役割が違う。
②ユニットテスト（単体）と統合テスト（連携）を取り違えない。
③Binary Authorization はデプロイ時の信頼検証で、ビルドそのものではない。
3.2.3この節のまとめ
- Cloud Build でソースからビルド、Artifact Registry に保存
- Binary Authorization でプロベナンスを保証し信頼できる成果物だけデプロイ
- ユニット/統合テストを CI（Cloud Build）に組み込み変更ごとに自動検証
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ソースコードからコンテナイメージをビルドする CI サービスはどれですか？
Q2. ビルドしたコンテナイメージやパッケージを保存するレジストリはどれですか？
Q3. デプロイ時に成果物の出所（プロベナンス）を保証し、信頼できるものだけ許可したい。使うのはどれですか？
Q4. 複数コンポーネントの連携を、変更ごとに自動で検証したい。最適な方法はどれですか？
Q5. ユニットテストと統合テストの違いとして正しいものはどれですか？
Q6. Cloud Build と Artifact Registry の役割の違いとして正しいものはどれですか？