マイクロサービスのテスト

第7章

テストの種類

• 実践アジャイルテスト
• 技術-ビジネス、プログラミング-製品の2軸で4象限にわけられる
  • 単体テスト
  • 性質テスト
  • 受け入れテスト
  • 探索的テスト
• テストピラミッド
  • 単体テスト
  • サービステスト
  • エンドツーエンドテスト
• アンチパターン：テストスノーコーン

サービステスト

• サービスの機能テスト
• 下流の連携先はモック/スタブ化する
  • スタブ
    • 既知のリクエストに対して決められたレスポンスを返す
  • モック
    • スタブの動作に加え、呼び出しが行われたことを確認する
  • モックかスタブか
    • 著者はサービステストではスタブをより多く使う
  • 実践テスト駆動開発
  • テストダブル
• スタブサーバは基本は自分で作る
• こういうサービスも使える
  • http://www.mbtest.org/

エンドツーエンドテスト

• やるべきか
  • 欠点が多い
    • 遅い
    • テストが脆弱になりやすい
    • 「誰が書くか」が問題になりやすい
      • 任意のチームの開発者が書く
        • サービスを結合したテストなのでエラーになったときに誰の責任なのか曖昧になる
        • 自分の担当のサービス以外が原因で落ちたとき
      • 専任のチームで書く
        • チームをまたぐためコード作成からテストの結果が見られるまでが遅くなる
        • 開発者がテストから離れると、テストが落ちたときに直し方がわからなくなる
      • どちらにせよ解決が難しくなりがち
• コンシューマ駆動契約
  • 呼び出し側（コンシューマ）視点でサービステストを実行する
  • Pact
    • https://www.gitbook.com/book/pact-foundation/pact/details
  • エンドツーエンドテストへの依存を薄めるのに活用できる

デプロイとリリースの分離

• スモークテスト
  • 新たにデプロイする環境に対し、本番環境へのリクエストを使って試験を行う
• カナリアリリース
  • 新たなバージョンを一時的に旧バージョンと並行稼動させ、期待道理に機能することを確認する

まとめ

• すばやいフィードバックのために、前提として単体テストは充実させる
• サービステストによってサービスの振る舞いを守る
• エンドツーエンドテストは最低限にする
• テストにより保証することも重要だが、デプロイ後にコードが正しく機能していることを確認する方法を把握しておく必要がある