最近キーワード駆動テストがややバズワード化している傾向を感じている。というのも、キーワード駆動テストの導入で無用な手間を増やしている場面を見るようになっているためだ。
キーワード駆動テストはフレームワークによっては手間を増やすことがあるので、その導入にあたっては、導入内容が目的に見合っているか多少の注意を向ける必要があると感じる。基本的な事柄であえて言及する必要もない内容かも知れないが、今回はそれについて簡単に触れたい。
キーワード駆動テストの目的
言及するまでもないかもしれないけれども、何かしらの改善を行う際は、その手段が目的に見合っているか留意する必要がある。ではキーワード駆動テストの目的は何かというと、大雑把にまとめて以下の３つがある。なおこれは排他ではなく、一緒に目指しても良い。
目的(1)テストの保守性改善
まず目的の一つに、テスト設計やテスト実装物の保守性改善のための構造化手段として、キーワード駆動テストを導入する場合がある。例えば以下のような目的だ。
- 重複テストコードを共通ロジックに、非重複テストコードをキーワードに展開してテストスクリプトのコピペを削減し、保守のミスを防ぐ。
- 可変性分析で抽出した流動的要素をキーワードに展開することで、テストケースやテストコードの変更性を高める。
キーワード駆動テストの導入の注意点：目的を取り違えないこと
目的(2)のツールを導入する場合の注意点
まず、見ていて注意が必要だと感じているのが、上記の目的(1)目的(3)の達成のために、目的(2)の用途のフレームワークや技術を導入してしまうパターンだ。
目的(2)のために作られたフレームワークは、非技術者でもテスト設計を担当できるようにする。その代償として、保守性の作りこみに制限をかけたり、キーワードをテストスクリプトに落としこむ手間でテスト実装の効率性を落としたりすることがある。極端な例だと、「テストケース仕様をExcelで書くようにして構成管理コストを悪化させる」「テストケースのフォーマットをキーワード形式に無理に合わせるためにテストの可読性を犠牲にする」といったものがある。
そのため、目的(2)のフレームワークを導入すると、目的(1)(3)の達成を難しくする場合がある。そして上記でも軽く触れたけれど、商用のキーワード駆動テストのフレームワークは目的(2)の用途を想定したものが多いので注意が必要だと感じる。目的(2)の達成も十分価値があることだけれど、その価値が活かせない環境ならば、手間が増えるだけになってしまうかもしれない。
目的(1)(3)の改善が必要な場合の注意点
一方、目的(1)目的(3)が要求される状況では、背景としてそもそもテストスクリプトの品質の悪さが根本原因である場合が少なくない点に留意が必要だ。フレームワークを導入してキーワード形式でフォーマットを固定するよりも、愚直にテストスクリプトの設計改善を行ったほうが問題が解決することがある。
コードやスクリプトの形式をフレームワークで固定して設計品質を向上させるのはDIやバインディングなどであるけれども、それは設計品質の向上を意図して作られているからできるというのを忘れてはいけない。
目的(2)の改善が必要な場合の注意点
また目的(2)が要求される場合、そもそもスキル的な問題が根本原因にあることがある。そこではフレームワークを導入するより、テストスクリプトを書けるように教育・人員確保を行ったり、スクリプトの保守性を上げて部分的にでも非開発者がメンテナンスできるようにしたほうが、全体の生産性が高まる場合がある。
あと目的(2)については、キーワード駆動テストにスクリプトを無理に合わせこむことで、ユーザ等にとってかえってテストがわかりにくくなり書きづらくなることがある。今では柔軟なDSLでテストを書けるフレームワークが複数出ているので、キーワード駆動テスト以外の選択肢の必要性も考慮したほうが良いと思う。
