Cucumberに出会ったので、ソフトウェアテストについてつらつら書いてみる。
ソフトウェアの開発工程を終えて、納品前のテスト工程というと、Excelの表に様々な操作パターンが書いてあってそれに従って操作して想定通りの動作をするかどうか○か×を付けていく。という地道な作業でした。というか今でもそうか。ちなみに僕が独立して最初に頂いた仕事は、開発ではなく、とあるPOSシステムのテスト要員でした。一日中ただ○を付けていくだけの簡単なお仕事ですを２週間ほど。悪いことにテスト仕様は開発サイドで作られる場合も多く、「想定外の操作」がテスト仕様に入らないので、そもそも×なんか出ないことが多いのです。やり方によっては納品物としてのテスト報告書を作るためだけの無意味な工程になってしまう。でも本来テストは品質保障のための重要な工程です。
びっくりだけどもう10年近くも前になるのか。アジャイルとかXPとかいう開発手法が話題になりはじめ、特にその中の1要素であるテスト駆動開発（TDD）という手法が注目されました。プロジェクト全体を今すぐアジャイルに切り替えるのはイロイロな事情から難しいところがあったとしても、TDDだけならプログラマ個人の判断で導入できることから爆発したんではないかと推測されます。
当時僕も非常に魅力を感じて試行錯誤してみました。しかし最初は面白かったけど結果としてはイマイチうまく回りませんでした。テストを書きすぎてしまうと、ちょっと内部仕様が変わっただけでもテスト通らなくなってしまい、リファクタリングしやすくなるはずが逆効果だったり、さじ加減がよくわからない。テストを書く工数もバカにならない。そのうち面倒になって実装先行になってしまう…
しかし先進的なプログラマは皆TDDを実践しているような気もするので、なんとかコツを掴みたいところ。…独学じゃなくて１度くらいTDDやアジャイルで回ってるプロジェクトに参加したかったような。
そんな中すこし前にちょっと心踊ったのはSelenium。前述のExcel人力テストの最大の欠点はリグレッションテスト（回帰テスト）ができないということです。プログラムというのは一箇所変更すれば影響はアプリケーションの多くの箇所に及びます。うまく作られたプログラムほどそうなるのです。だからちょっとでもプログラムを変更したら毎回アプリケーション全体のテストをしたいのです。手動だとテスターに睨まれるけど、Seleniumならこれが自動化できる！
確実に役に立ちそうなシステム。でもなぜか使う機会がありませんでした。やはりプログラマ視点だとTDDじゃないとテストする気にならないからかなあ。テスト用サイトの環境を作るのが面倒というのもあったかも。
Cucumberというテスティングフレームワークに出会ったのは、2月のデブサミでの@moro氏の講演だったかな。その時は、「Seleniumと何が違うの？SeleniumのほうがWebブラウザ上でテストケース作れるし楽じゃね？」くらいにしか思っていませんでした。
で、今回そのCucumberをやっと試してみることができまして、その絶妙な立ち位置に使い勝手の良さを予感してしまいました（←いまここ）。想定しているレイヤーは「受け入れテスト」的な部分で、確かに純粋に受け入れテストにも使えそうなコーディング量。かつTDDにも使えるという点が良さげ（本来受け入れテストとテストファーストにおけるテストは相反するフェーズのはずだけど）。人力テストから無理なく移行できそうで、「この粒度なら僕にもTDDできるかも！」という期待感。複雑なロジックに対してはRSpecなどを併用してしっかりユニットテストする。これならかつて悩んだ「テストボリュームのさじ加減」が掴めるかも。
今のところ問題はJavaScript関係かな。Seleniumと組み合わせてAjaxのテストもできるようだけど、いきなり面倒な感じになるような…。
