E2Eテスト vs E2Eテスト [API仕様ファースト開発]
私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。
どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト／テスト駆動開発」からそのまま引用します。
この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。
テストピラミッドの例
このテストピラミッドでは、「統合テスト」は、依存しているサービスへの呼び出し部分をモックで置き換えてサービス単体でテストすることを指すことが多いです。したがって、依存しているサービスへの呼び出しを、テスト時だけモックで置き換えられるような仕組みを埋め込む必要があります。つまり、本番環境で動作するコードの動作を確認しているわけではありません。
たとえば、実際に本番環境（もしくは開発用環境）で依存するサービスを呼び出したら、呼び出しコードに間違いがあり、モックとは異なる動作をしたり、正しく動作しなかったりする可能性があります。
そのため、統合テストの次の上の段階で行いたいのは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うことになります。
この時に、依存するサービスをどうするのかという問題に直面することになります。その結果、一般的な書籍で述べられている「E2Eテスト」ということになります。しかし、それは他の依存するサービスも動作させないといけないし、それらのサービスが動作するためのデータベースの設定が必要かもしれなく、設定が非常に面倒になります。
その結果、一般的な書籍では、E2Eテストは構築が難しいくテスト時間も要するので、単体テストや統合テストを強く勧めています。
当時は、ほぼすべてのマイクロサービスが同時に開発されており、私が担当するマイクロサービスが依存するマイクロサービスも開発中という状態でした。それで考え出したE2Eテストです。
考え出した背景は、次の通りです。
2019年12月14日に開催されたGDG DevFest Tokyo 2019で最初の発表を行っています。
どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト／テスト駆動開発」からそのまま引用します。
この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。
一般的なE2Eテストとは
一般的な書籍では、テストピラミッドにおける頂点にあるE2E（End-To-End）テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境（たとえば、Docker、あるいは開発用のクラウド環境）にデプロイして「加盟店管理用APIマイクロサービス」をテストすることを指すものが多いです。テストピラミッドの例
このテストピラミッドでは、「統合テスト」は、依存しているサービスへの呼び出し部分をモックで置き換えてサービス単体でテストすることを指すことが多いです。したがって、依存しているサービスへの呼び出しを、テスト時だけモックで置き換えられるような仕組みを埋め込む必要があります。つまり、本番環境で動作するコードの動作を確認しているわけではありません。
たとえば、実際に本番環境（もしくは開発用環境）で依存するサービスを呼び出したら、呼び出しコードに間違いがあり、モックとは異なる動作をしたり、正しく動作しなかったりする可能性があります。
そのため、統合テストの次の上の段階で行いたいのは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うことになります。
この時に、依存するサービスをどうするのかという問題に直面することになります。その結果、一般的な書籍で述べられている「E2Eテスト」ということになります。しかし、それは他の依存するサービスも動作させないといけないし、それらのサービスが動作するためのデータベースの設定が必要かもしれなく、設定が非常に面倒になります。
その結果、一般的な書籍では、E2Eテストは構築が難しいくテスト時間も要するので、単体テストや統合テストを強く勧めています。
私が定義しているE2Eテストとは
私がマイクロサービスの開発とテストファースト／テスト駆動開発」や「WEB+DB PRESS, Vol.134」の特集1「実践API設計」で述べているE2Eテストは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うのですが、以下の点が異なります。- 本物の依存するサービスは使わない
- 開発者の開発PC（たとえば、MacBook Pro）上でローカルにテストが実行できる
必要に迫られて開発した方法
2018年6月にメルペイに入社して、本格的にウェブサービスのバックエンドサービスの開発に従事するようになって担当したのが、上の図にある「加盟店管理用APIマイクロサービス」です。当時は、ほぼすべてのマイクロサービスが同時に開発されており、私が担当するマイクロサービスが依存するマイクロサービスも開発中という状態でした。それで考え出したE2Eテストです。
考え出した背景は、次の通りです。
- 自分が開発を担当するマイクロサービスの開発・テストが終わったと責任を持って言えるようにするにはどうすればよいか
- マイクロサービスが定義しているAPIの仕様に書かれている動作をすべて自動テストで確認してから、フロントエンドの担当者に、マイクロサービスの開発が終わっているので使ってくださいと言いたい
2019年12月14日に開催されたGDG DevFest Tokyo 2019で最初の発表を行っています。
〓GDG DevFest Tokyo 2019 ご登壇者紹介〓
— GDG Tokyo (@gdgtokyo) November 16, 2019
Main Sessionにて柴田 芳樹さんにご講演いただきます。『マイクロサービスの開発とテストファースト/テスト駆動開発』と題して、merpayのバックエンドエンジニアとしてどのような手順で開発し工夫をしているのかなど紹介いただきます。 #DevFest19 #gdgtokyo pic.twitter.com/IZG1rglNCT
2023-11-08 17:12
コメント(0)
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
