APIテスト自動化のススメ~Karateでデータ駆動型テストを並列実行しよう~
こんにちは、QAを行っている矢野です、 前回書いたAPIテスト自動化についての記事ではAPIテストの重要性とその自動化ツールKarateについて紹介させていただきました
今回はテスト自動化すると非常に恩恵のあるデータ駆動型テスト(Data Driven Test/DDT)の話と、Karateでどのように実装するかを書かせていただこうと思います
データ駆動型テストについて
まずデータ駆動型テスト(DDT)自体をあまり聞いたことのない方もいると思うので簡単に説明をします
例えばGUIを用いたテストだと同じテキストボックスにさまざまな値を入力してクリックしたときの期待値を確認したいといったケースがあります
APIのテストだと様々なパラメータやリクエストメソッドで期待値を検証することも多いと思います
テストの中で異なるデータを入力や検証で使用はするけど、基本的な操作が同じようなテストの場合、一度作成したテストシナリオを再利用可能な形にできるとメンテナンスもしやすくなりありがたいですよね？そういったときにDDTを用いることができます
またDDTはテスト自動化の中でも作成するテストコード自体は少なくなるのでメンテナンスもしやすく、データセットのパターン数に応じて何度も再利用できるので自動化した際に恩恵を受けやすいです
組み合わせテストとデータ駆動型テストの関係
どのような場合にDDTを用いた実装をするかというと有則、無則を問わず組み合わせパターンの多いテストに効果的です
因子水準から導き出されたマトリクス表においてはテストケースが膨大になりがちです
そのテストケース1つ1つを手動でやるのも大変時間がかかりますし、それぞれのパターンでテストコードを一つ一つ書いていくと記述量が大変なことになってしまいます
他にもBDDスタイルで記述可能なKarateでは、SBE(Specification by Example) といった実例を用いて仕様を書きながら、テストに実装することもあるかと思います
そういった場合の実例は一つではなく複数パターンになることも多いので、DDTとも相性が良いです
KarateでのDDT実装方法
実際にKarateリポジトリにあるシナリオアウトラインのサンプルを見てみましょう
Scenario Outline: given circuit name, validate country
Given path 'api/f1/circuits/.json'
When method get
Then match $.MRData.CircuitTable.Circuits[0].Location.country == '<county>'
Examples:
| name | country |
| monza | Italy |
| spa | Belgium |
| sepang | Malaysia |
https://github.com/karatelabs/karate#data-driven-tests
Scenarioの代わりにScenario Outlineと書き、データセットはExamplesに書くことで各データでのテストが繰り返し実行されます
この記述から分かるようにデータセットがあまり多くない場合は、featureファイルに記述していくのでも問題にはならないのですが、データセットが肥大化していくとかなり見づらいものとなります
そんなときはAPIテスト自動化ツール「Karate」現場ですぐに使える実装パターン8選(前編)に記述されている通り、データセットのファイルは外部に出してテスト実行時に読み込むことで可読性も良くなりデータセットの管理も簡単になります
Karateでの並列実行の方法
大量のデータセットを用いたDDTを行う際は実行するテストが膨大に増えていくのはお気づきの通りで、テストの実行時間がかかるといった問題がでてくるかと思います
そこでKarateではマルチスレッドによるテスト実行の並列化が標準でサポートされているので、並列実行でテスト実行時間を短縮することが可能になります
APIのテストを自動化する時点でかなりのテスト量になると思いますので、DDTのテスト以外にも並列実行はもちろん使えます
詳しくはAPIテスト自動化ツール「Karate」現場ですぐに使える実装パターン8選(後編)にも書いてある通り、記述を次のように変えるだけです
@Test
public void runParallelTest() {
Results results = Runner.path("classpath:scenarios").parallel(5);
assertEquals(0, results.getFailCount(), results.getErrorMessages());
}
GUIのテストだけで組み合わせテストの全パターンを実施するのは大変ですが、ユニットテストやAPIのテストでも組み合わせテストをDDTで実施して適切にテストの実行時間やテストのメンテナンスを軽いものに移行できると理想的だと思います
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：矢野 崇
SHIFTの在宅勤務エンジニア第一号。QAや自動化、可視化は好きだが、テストは受験戦争のトラウマがありあまり好きではない。より良いモノをより良くツクルためにはどうすればいいのか模索している。 最近注目しているものはヴィパッサナー瞑想。
【FREE】お役立ち資料ダウンロード
お問合せはお気軽に
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/