APIテスト自動化のススメ ～テストの悩みをKarateで解決～
こんにちは、QAを行っている矢野です。
突然ですがAPIのテストは実施されていますか？
そしてAPIテストの自動化は行っていますか？
最近では開発者が率先してユニットテストを書くことも増えてきたと思います、しかしユニットテスト以外は書いていないというケースもよく聞きます。
逆にテスト担当者がいるところだと昨今流行りのキャプチャ＆リプレイツール等を用いたテストは自動化されているけど、それ以外のテストは書かれていないことも多いのかなと感じています。
近年はモバイルアプリの普及やマイクロサービスアーキテクチャの浸透でAPIが非常に多く利用されるようになっており、WebAPI自体をプロダクトとして外部に公開や連携するといったケースも増えています。
それに伴いAPIの品質を担保する需要が上がり、APIテストの実施や自動化をするといった動きが広がっていると思います。
本記事では普及しつつあるAPIテスト自動化に関して、事例を軽く交えつつまとめたいと思います。
APIテスト自動化のメリット
まずはAPIテスト自体を自動化することのメリットを整理したいと思います。
昨今のアジリティが求められる開発現場において、頻度の高いリリースの度にAPIのテストを毎回curlコマンドなど用いて手動でやることはとても大変ですが、一度自動化してしまえば何度でも繰り返し実行が可能です。
テストピラミッドで考えた時もピラミッドの中段にあたり、実行時間もユニットテストほどではなくとも比較的高速ですし、画面の変更などに影響を受けるテストではないのでテストメンテナンスのコストもそこまで多くはかかりません。
以前の記事にも書かせていただいたように、ピラミッドの上段ばかりを自動化してしまうことはアンチパターンになりますし、かといって下段ばかりを自動化するとSUT (System Under Test) の再現度の低いものしかテストできませんが、APIテストの自動化を用いることで全体のバランスがとりやすくなるのが魅力だと思います。
そして、テストを自動化したらCI環境で実施することも可能なので、デプロイパイプラインに組み込むことで、シームレスなテスト実行も可能になります。実際にGitHub Actions上で実行して運用できています。
APIテストで可能なテストタイプ
APIのテストで可能なテストタイプは非常に多岐にわたります。機能面でのテストはもちろんのこと、利用ユーザのシナリオにおけるAPIの呼び出しをテストするといったシナリオテストや、性能テストや負荷テスト、そしてセキュリティテストなども可能です。
またGUIを用いたテストだけだと非常にパターンが多くなり、時間がかかるようなテストもAPIのテストをうまく組み合わせることで下図のようにパターンを効果的に削減することができます。
Karateの特徴とメリット
APIテスト自動化で実際に使用したKarateについて簡単に説明します。
2021年3月にv1.0.0がリリースされたツールで、Gerkin記法を用いたDSL(Domain Specific Language)を書くことでテストの実装が可能です。
そしてAPIのテストだけでなく、性能、負荷試験(Karate Gatling)も可能で、テストダブル機能(Karate Netty)もあります。そしてAPIだけでなくGUIを用いたテストもでき、Karateひとつで非常にできることが多いツールであることが下図からも読み取れるかと思います。
ツール選定の際に注目したポイントは以下になります。
1. テストコードやレポートの可読性が高かった
2. Gatling連携で性能や負荷試験にも使える
3. テストダブル機能もある
4. 国内での導入事例も存在する
Karateの書き方サンプル
本記事では簡単なサンプルでKarateでのテストの書き方を説明します。
KarateではFeatureファイルにテストシナリオを書いていく形になり、シナリオはGiven, When, Thenの三つで構成されます。
Feature: Karateテスト書き方サンプル
# 各テストシナリオ前に実行される
Background:
* url 'https://myhost.com/v1/'
Scenario: Getメソッドでリクエストしたときのレスポンスのチェック
# テストの前提条件(リクエスト先、ヘッダ、ボディなどリクエスト内容を記述)
# urlと合わせて 'https://myhost.com/v1/hoge'がリクエスト先
Given path 'hoge'
# テストのアクション(リクエストメソッドを記述)
When method get
# テスト結果アサーション(レスポンスコードやボディの期待値を記述)
Then status 200
And match response == '#object'
And match response.id == '#notnull'アサーションも豊富で、完全一致以外にもFuzzy Matchingでデータの型などをチェックすることができ、正規表現によるチェックも可能になっています。
しっかりとAPIの仕様を事前に決めておくことができれば、テストを先に書いておくことも可能で所謂、BDD(Behavior Driven Development)も可能です。
本記事では詳細は割愛させていただきますが、 Karateの標準機能でできないことをテストでやる必要性も実際にはありましたが、JavaやJavaScriptでメソッドを用意してそれをシナリオから呼び出す形で柔軟に対応可能です。
他にも因子水準があるような複数パターンでのテストでは、データ駆動テスト(DDT: Data Driven Testing)も非常に簡単に書くことができてとても便利です。
宣伝
画面を用いたテストだけを実施して時間がかかっていませんか？
受入テストの最中やリリース直後にバグが発見されることはありませんか？
下図のように欠陥の発見は工程が後ろになればなるほど、修正にかかるコストが爆発的に増加することは現場でも実際によくあることかと思います。
修正コストの爆発的増加を防ぐためにはシフトレフトテスティングをして品質を作りこんでいくことが望ましく、APIテスト自動化はその手段のひとつとして使えます。
SHIFTではAPIテストや自動化の実績も多くあり、今回ご紹介したKarate以外にも現場に最適なツールのご提案とテスト自動化推進をいたします。
テスト自動化の必要性についてはSHIFTのオウンドメディア「シフトモ」の記事にもまとめてあるのでご覧いただければ幸いです。
テスト自動化支援についてはこちらからご相談ください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：矢野 崇
SHIFTの在宅勤務エンジニア第一号。QAや自動化、可視化は好きだが、テストは受験戦争のトラウマがありあまり好きではない。より良いモノをより良くツクルためにはどうすればいいのか模索している。
最近注目しているものはヴィパッサナー瞑想。
★このSHIFT公式ライターの他の記事を見る
テスト自動化のアンチパターンをご紹介ーテスト自動化が失敗する原因ー
SeleniumでSPAのE2Eテスト自動化はできないのか？
■SHIFTについて
私たちはソフトウェアテスト(第三者検証)のプロ集団です。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/