Postmanの導入効果をレビューでご紹介(uribou-株式会社スマートバンク)

• 初期開発において、複数のシステム（マイクロサービス）から成り立つ決済の API に対する E2E テスト環境を構築する必要がありました
• この API の結果を利用した非同期処理のテストも同時に行う必要がありました
• シード期のスタートアップのため、できるだけ構築コストを下げてテスト環境を構築する必要がありました

Postman 導入前は、integration テストまでは各サービスで自動テストを作成していましたが、E2E テストは作成していませんでした。そのため、テスト対象は1つの API であるものの、決済の様々なパターンに対応した多数のテストを手動で実施する必要があり、工数がかかっていました。

他社のブログなどで、Postman を E2E テストで利用している事例を把握していたため検討を始めました。

scenarigo

• GUI で簡単にテストケースの作成や実行ができる
• CUI での実行もサポートされており CI への組み込みも容易
• テストケース実行前・後にスクリプトを自由に挿入できるなど、拡張性が高い

導入当時はエンジニアが3人程度だったため、導入にあたって特別な推進作業は必要ありませんでした。

一方で、コスト観点から CI 環境への組み込みはしておらず、ローカル環境で各開発者がテストツールを実行する必要があったため、どのような時にテストを実行する必要があるか開発者が判断する必要がありました。

この判断を確実に行うため、決済周りのテストツールが存在することを認知してもらい、決済システムの定期的な勉強会やオンボーディング資料に明記しました。また、決済周りのコードレビューでテストツールを実行するようコメントするようにしたことで、テストツールが存在することが周知され、自分が関係していない PJ でも自然と利用されるようになりました。

API の E2E テストのカバレッジを高く保つのは、コスト観点から非常に大変です。私達がサービスのコアな機能である決済部分でのみ E2E テストを用意したように、重要度の高い部分に絞りテストを用意するので充分な場合があるかもしれません。 また、E2E テストの仕組みを構築することと、CI 環境を構築することはイコールではありません。まずは、実行環境はローカルでもよいので E2E テストを自動で行う仕組みを導入するところからスタートするなど、初期の導入コストを低くすると始めやすくなるかもしれません。