Web API設計実践入門──API仕様ファーストによるテスト駆動開発

構成数 : 1枚

はじめに

■第1章 ソフトウェアテストの変遷

1.1 1990年代までと2000年代のソフトウェアテスト
目視確認が普通だった
自動テストの普及
手動によるテストでは、ソフトウェアが腐る
1.2 フィードバックループを短くする
テストとフィードバックループ
テストファースト開発
1.3 ビッグバンインテグレーションから継続的インテグレーションへ
ビッグバンインテグレーション
夜間ビルド
継続的インテグレーション
1.4 まとめ

■第2章 API仕様

2.1 APIとは
フレームワークや標準ライブラリのAPI仕様
企業内でのAPI仕様
2.2 優れたAPI仕様とは
理解が容易
変更が容易
テストが容易
2.3 API仕様でよくある問題点
API仕様が記述されていない
エラーの説明が記述されていない
API仕様に基づく自動テストコードが存在しない
2.4 API仕様に書くべきこと
サービスの概要の説明
個々のエンドポイントの説明
エラーの説明
2.5 API仕様とE2Eテスト
2.6 まとめ

■第3章 gRPCにおけるAPI仕様の書き方

3.1 gRPCとは
3.2 API仕様をどこに書くか
3.3 サービスの概要の説明
3.4 個々のエンドポイント(RPC)の説明
3.5 エラーの説明
パラメータの不正
誤った順序での呼び出し
認証や認可のエラー
サービスの概要に書くべきそのほかのエラー
個々のエンドポイントに書くべきそのほかのエラー
書く必要がないエラー
3.6 リストオプションの説明
3.7 まとめ

■第4章 API仕様ファースト開発

4.1 開発順序
API仕様の記述
E2Eテストフレームワークの検討と実装
テストコードの作成と機能の実装
リファクタリングとカバレッジの確認
Pull Requestのレビュー
4.2 不具合の修正順序
再現テストの作成と実装の修正
リファクタリングとカバレッジの確認
4.3 既存のエンドポイントの修正と新たなエンドポイントの追加
4.4 API仕様のエンドポイントを呼び出すE2Eテストの利点
4.5 まとめ

■第5章 E2Eテストフレームワークの構築

5.1 テストフレームワークの基本的な考え方
本番環境と同じバイナリ
カバレッジの取得
5.2 マイクロサービス構成でのテストフレームワーク
書きたいテスト
E2Eテストフレームワークのプロセス
依存サービスが外部サービスの場合の解決方法
エラーのテストは簡単
5.3 非マイクロサービス構成でのテストフレームワーク
5.4 E2Eテストフレームワークの骨格
Test Suiteプロセスの骨格
テスト対象マイクロサービスの骨格
フェイクマイクロサービスの骨格
テストコードの骨格
そのほかの考慮項目
5.5 まとめ

■第6章 API仕様の技術的負債の返済

6.1 APIの技術的負債とは
E2Eテストフレームワークの構築が重要
ソフトウェアエンジニアとしても重要
ソフトウェア開発組織としての強い目標
6.2 API仕様の負債の返済
既存のエンドポイントを修正するケース
新たなエンドポイントを追加するケース
既存のエンドポイントの不具合を修正するケース
6.3 返済順序のまとめ
6.4 E2Eテストのもう1つの利点:リファクタリング
6.5 E2Eテストと単体テスト
E2Eテストは必須
テストデータの準備
データの準備でつまずく
6.6 API仕様ファースト開発が定着した組織
6.7 まとめ

■第7章 Go言語によるE2Eテストフレームワークの実装

7.1 E2Eテストの基本的な流れ
Test Suiteプロセスの流れ
7.2 courierライブラリの構成とインストール
インストールと動作確認
7.3 サンプルサービスの構成と定義
サンプルサービスの構成
Shopサービスの.protoファイル
.protoファイルのコンパイル
サンプルサービスで実現したいテスト
7.4 E2Eテストコードの例
InvalidArgumentエラーのテストコード
newShopClient()関数の実装
テストの実行
7.5 E2Eテストフレームワークの流れ
フェイクサービスの実行
テスト対象サービスの起動
テスト対象サービスの準備待ち
テストの実行
テスト対象サービスの終了
7.6 フェイクサービスの構築
フェイクサービスの自動生成
自動生成されたフェイクサービスのコード
7.7 テスト実行までの流れとテストコードの実装
TestMain関数
テスト対象サービスが依存する環境変数
テスト対象サービス...