Webクライアントのテスト

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
先日、魔女の宅急便を見ました。映画の最後で語られる「おちこんだりもしたけれど、私はげんきです」のメッセージに、とても励まされた、たなけんです。(ダイエットに挫折しそうになっていたため。。。)
本エントリでは、Webクライアントのテストについて記載します。

Webクライアントのテストの位置づけ

Webクライアントのテストの為に、今回テスト手法やテスト用ライブラリなどを調査しました。その結果、いくつかの興味深いフレームワークやライブラリ、ツールを見つけることができました。
しかし、今回のWebクライアントは

• ソースコードが実質20行程度と非常に短い
• 条件分岐がなく一本道のロジックである

ことから、それらのライブラリを利用してテストする程ではないと考えました。
本来であれば、クライアントのメソッド単位で、まずは単体テストを実施し、その後ユーザの操作フローに基づいた結合テストを実施します。また、正常系だけではなく、異常系も漏らす事無くテストするのが本来のテストの姿であると考えています。
しかしながら今回は、Webクライアントの機能が十分すぎる程シンプルであるため、テストの目的を、デグレーションの検出に限定して考えたいと思います。

テストプログラム実装方針

正常系の動作を自動実行し、以上が発生しない事を確認する。
ライブラリとしてSeleniumをラップしたclj-webdriverを利用する。

依存ライブラリのダウンロードの問題

project.cljにclj-webdriverを利用するよう記載し、lein depsを実行したところ、bcprov-jdk15on-147.jarおよびbcpkix-jdk15on-147.jarのダウンロード時に、チェックサム例外が発生し、Leiningen経由では上記2ライブラリがインストールできませんでした。
そこで新規Mavenプロジェクトを作成し、Seleniumの依存ライブラリをインストールしたところ、問題なく上記2ライブラリをインストールすることができました。
私の環境ではLeiningenとMavenでライブラリを共有しているため、この方法で解決をすることができました。
また、Maven利用の前にlein-localrepoによるfloating jarのローカルインストール(Mavenの3rd party jarのインストールのようなもの)を試してみましたが、こちらは上手くいきませんでした。

テストコード

	(ns test-my-dictionary.core
	(:require
	[clj-webdriver.taxi :as wd]))
	(defn main
	""
	[]
	(do
	(wd/set-driver! {:browser :firefox} "file:///Users/kenta/clojure/my-dictionary-client/dictionary.html")
	(wd/implicit-wait 10000)
	(wd/input-text "#query-word" "test")
	(wd/implicit-wait 10000)
	(wd/click "#dictionary-button")
	(wd/implicit-wait 10000)
	(wd/find-element {:xpath "//tbody/tr/td"})
	(wd/quit)))

view raw core.clj hosted with ❤ by GitHub

• doマクロ: 手続き型のプログラミング言語のように、以下のS式を順に処理する
• clj-webdriver.taxi/set-driver!関数: ブラウザを起動し、引数のurlを開く
• clj-webdriver.taxi/implicit-wait関数: 指定ミリ秒処理を停止する
• clj-webdriver.taxi/input-text関数: テキストボックスに引数の文字列を入力する
• clj-webdriver.taxi/click関数: 引数の要素をクリックする
• clj-webdriver.taxi/find-element関数: 引数で指定された要素を取得する。要素はxpathなどで指定が可能

clj-webdriverの感想

依存ライブラリのダウンロードで問題が発生するなど、アルファバージョンにつきものの不安定さはありました。
その反面、一度インストールしてしまえば、非常に短いコードでSeleniumを用いたテストを記述することができました。
業務ソフトウェアをClojureで書くよう周囲を説得するのは難しいと思います。しかし、clj-webdriverのように、テストツールとしてClojureを導入するのは、非常に現実的な選択肢ではないかと、clj-webdriverを使ってみて強く感じました。
(通常の単体テストも、JUnitの代わりにテストだけClojureで書くことも出来そうですね)

今後利用してみたい、Javascriptテストの技術要素

今回のテスト(そもそもロジックがない)で利用するにはオーバースペックでしたが、Clojurescript (Javascript)のテストに関連する様々なフレームワークやライブラリ、ツールについても多少調査したため、この場を借りて紹介します。

Jasmine

Javascriptテスティングフレームワークの大本命。
Google Closure Library (Closurescriptを影で支えているJavascriptライブラリ)はJsUnitを公式テストフレームワークとして採用しています。しかし今やJsUnitはメンテナンスされておらず、JsUnitのサイトでもJasmineへの以降を推薦していました。
Clojurescriptをテストする方法が、Odyssomayさんのブログに分かりやすく解説されています。(なぜClojurescriptをビルドするためのスクリプトがPythonで書かれているかは追求しません。。。)

Sinon.js

Javascriptの柔軟性を存分に活かした黒魔術のようなライブラリ。単体テストの際、関連オブジェクトを差し替えてテストしたいといった要望は多々あるかと思います。(テストするクラス以外は、単純にある値を返して欲しいなど)
Sinon.jsはオブジェクトのスタブ化、モック化またフェイクサーバやフェイクタイムなどを提供し、オブジェクトを差し替えたいといった要望に応えてくれます。
モックあるいはスタブ化関数で処理することで、テスト対象以外のオブジェクトは、メソッドインタフェースは普遍のまま、振る舞いをテストに都合の良いように変えることができます。
同じ様なコンセプトのライブラリ、是非ともClojureにも欲しいなあと感じました。(JavaでSpring frameworkなど使えば、同様の機能は実現可能ですが、Clojureの持つ柔軟な言語特性を活かしたライブラリがあればもっと手軽に実現できそうなので)

PhantomJS

Javascriptのテストライブラリはブラウザから実行することが多いのですが、ブラウザの起動や動作までサポートするライブラリはあまりありません。
PhantomJSはコマンドラインから起動でき、読み込んだJavascriptを実行することができるブラウザです。(内部で、WebKitエンジンを利用しています)
PhantomJSを利用することで、コマンドラインからJavascriptをテストすることができ、単体テストの自動実行が容易になるかと感じました。

今回の作業は以上。最後までお読み頂き、ありがとうございました。

たなけん(作業時間30分)