既存のテストフレームワークを使う
既存のテストフレームワークを使わなければならないという規則はないが、広く使われているテストフレームワークにはそれなりの利便性があるので、既存のテストフレームワークを使うのもよい選択肢だ。
特定のテストフレームワークに慣れておけば、別の開発プロジェクトを始めたときもテストコード記述のスキルを使い回せるというメリットがある。また、逆説的な利点となるが、テストフレームワークを利用するようにソフトウェアを書いたり、開発環境を用意したりするようになることで、プロジェクトやソースコードの整理が進むという側面もある。テストフレームワークはうまく使えばメリットが得られるのだ。
デメリットとしては、そのフレームワークの学習コストや、テストフレームワークの複雑さがもたらすことで発生する時間の消費といったところだろうか。これはバランスの問題なので、開発しているソフトウェアに合わないと思ったら別のテストフレームワークに変えればよいし、テストフレームワークを使わずに自前のテストコードだけを使うというのも常に選択肢としてとっておけばよい。
テストフレームワーク「Kyua」とは
今回は、テストフレームワークとしてKyuaを使った例を取り上げる。Windowsではあまり使われていないテストフレームワークだと思うので、以下を参考程度に読んでもらえればと思う。
Kyuaはソフトウェアパッケージの品質保証ツールチェーン。ソフトウェアに対して自動テストを実装して実行するためのライブラリとツールの集まりだ。主な特徴として、以下がある。
- 異なるプログラミング言語で開発されたテストプログラムやテストライブラリに対応。ATFライブラリに対応しているほか、ATFに対応していないプログラムにも対応
- テスト結果を履歴データベースへ保存。テストの出力、テストが失敗した場合のスタックトレース、テストが実行された環境、テストで発生した特定のエラーなどの詳細が保存されており、より詳しい分析に使用できる
- 履歴データベースに保存した記録からHTML形式やプレーンテキスト形式のレポートを作成
Kyuaは2007年にNetBSDで開発が始まったATF (Automated Testing Framework)と呼ばれる取り組みの後継版と言えるもので、2010年に開発が開始された。ATFはもともとNetBSDオペレーティングシステムの自動テストスイートを実装するためのライブラリとツールセットを提供することが目的とされていた。KyuaはそのATFが抱えていた課題を解決するために生まれたテストフレームワークであり、現在ではNetBSDのみならず、他かのオペレーティングシステムやプロジェクトでも利用されている。
KyuaはPOSIXベースのコードであるため、LinuxやMac、*BSDといったUNIX系のオペレーティングシステムで使いやすい。今のところ、公式にはWindows版は存在していない。著者がKyuaをよく使っているので、自分でWindowsに移植してWindowsでもKyuaを使っている。KyuaをWindowsで動作するように移植する話は、面白いのでいずれ取り上げるつもりだ。
今回はKyuaがWindowsで動くというところから話をはじめる。なお、本連載はKyuaの連載ではないので、kyuaの詳しい説明はしない。Kyua用のテストコードを追加して、kyuaコマンドで利用するということだけ把握しておいてもらえればと思う。