こんにちは。私はQA業務にはあまり関わりの無いイチSEですが、縁があり今回Quesに寄稿させて頂くこととなりました。
皆さんテストケース書いてますか？
昔は「テストするためにわざわざコードを書くなんて」とよく言われたものですが、最近では「テストの無いコードはレガシーコード」と言われるようになるほど、テストケースの作成というのは一般的になってきたように思います。今回は苦労して作ったテストケースをより有効に活用するためのCI(Continuous Integration)について少々お話をさせて頂きます。
テストケースは通常開発工程で作成されます。
自分の受け持ちモジュール ＋ それに対応するテストケース作成が必ずワンセットになり、テストケースの完了を以て開発完了となるケースが大半です。(テストの作成を先に行うTest-Driven Development、通称「TDD」という開発手法もあります)
ただ、ここでテストケースの役目が終わりになるわけではありません。むしろ開発完了後、モジュールに変更が入り、テストケースを再実行し結果を確認するという使い道の方が圧倒的に多いのです。メンテされないテストケースはただのゴミです。ここでよくあるのが「モジュールAに修正を入れたので、モジュールAのテストケースを実行し結果を確認した。問題無かったのでタスク完了とした。」というものです。
一見何も問題ないように見えますが「このモジュールAの修正により、関連クラスのモジュールBのテストケースが通らなくなってしまった」という場面が往々にしてあるのです。モジュールAに変更を入れた人がモジュールBの仕様を深く知っていれば防げたかもしれませんが、実際の開発現場ではなかなかそうはいきません。大規模開発になればなおさらです。
こういったケースを完璧に防ぐことは難しいでしょう。ですが、早期に発見することは充分可能です。全テストを定期的に、それも出来るだけ頻繁に行えば良いのです。この開発→全テスト→修正のフィードバックサイクルを出来るだけ短く回すプラクティスこそが「Continuous Integration」、CIです。
このCIを実現するためには、まずはソースコードのリポジトリにコミットが入るのを見張り、コミットされたら全テストを再実行し、結果をお知らせしてくれる要員が必要になりますね。大規模なプロジェクトになるとテストも多くなりますから、当然それだけの時間拘束されてしまいます。何の生産性も無い単純作業ですが、重要な仕事です。プロジェクトの誰かに泣いて貰いましょう。最初は抵抗するでしょうが、大丈夫。すぐ慣れます。
どうしてもそういった要員が調達出来ないという困った方には、こちらのとても素敵な執事をオススメします。
Mr.Jenkins です。
このダンディーなヒゲの紳士、皆が嫌がる単純作業を毎日でも毎時間でもいくらでも繰り返し繰り返しやってくれます。しかも、人件費はタダ！冗談のようなオジサマですが本当です。
嘘だと思う方はこちらをご覧ください。
Welcome to Jenkins CI! | Jenkins CI
https://jenkins-ci.org/
ね？本当にいたでしょう？
セットアップ手順はとても簡単なので割愛します。Google先生にでも聞いて頂ければ、いくらでも情報が出てくるはずです。サーバーが一台あればすぐにでも優秀な執事があなたに仕えます。「上司を説得出来なくてCIサーバーが用意出来ないよぅ」とお嘆きの方は、Windows版/Mac版もありますので、とりあえずローカル環境に導入してみては如何でしょうか。有用なものだと証明できれば、きっと上司の方も耳を傾けてくれるはず！(ただし、ローカル環境で実行する場合はかなりマシンリソースを消費します)
Jenkinsの特徴としては、オープンソースのプロダクトですので無償で使うことができ、400を超えるプラグインで必要な機能を拡張することが出来ます。分散ビルドも可能ですので大規模開発もバッチリ！しかもこの執事さん、出来るのはテストの実行だけではありません。コマンドで出来ることなら何でもやってくれます。私のプロジェクトで実際に行っている例ですが、テスト全実行→OKならビルド→検証環境のサーバーにデプロイといった振る舞いもお手の物です。こうすることで検証環境は常にテストが完璧に通り、動作が保証された最新版に保つことが出来るわけです。もちろんテストに失敗したらメールでお知らせして貰うことも可能ですので、前述の
「このモジュールAの修正により、関連クラスのモジュールBのテストケースが通らなくなってしまった」
というケースは、すぐに検知することができます。これにより開発者は他のモジュールを気にする必要がないので、目の前のコードに集中できます。開発者視点で言わせて頂くとこのメリットは大きいです。 「この改修で他のモジュールにバグが発生しないだろうか・・・」という不安から解放され、「何かあったらJenkinsさんが見つけてくれるさ」と安心し て自分の仕事に没頭出来るのです。(もちろんJenkinsでテストがNGだった場合は修正しないといけませんよ)
ちなみにですが、私のプロジェクトではJenkinsさんがNGを出している間は何があってもリリースはしません。お客様や関連各所と調整し、リリース日を決めてあとはデプロイするだけ、という状況でもJenkinsさんからのお許しが出ない限りはリリースを見送らせます。例えローカルでテストは通っている、検証環境で動作確認もした、でもJenkinsのテストだけがNGだ。という状況でもダメです。お客様や関連各所にお詫びし、リスケさせてもらいます。Jenkinsは優秀な執事であると同時に、信頼できるリリース監督でもあるのです。
ただしこの状況にするためには「メンバー全員が適切なテストケースを作成している」というのが大前提です。CIを導入することで、テストケースの作成が楽になるわけではありません。もちろん開発工数の圧縮にもなりません。CIは何かを作ってくれるツールではなく、あくまで品質を上げるためのプラクティスです。ですが、きちんと導入することで品質は必ず向上することでしょう。しないわけがありません。
どうですか？あなたのプロジェクトにも優秀な執事を迎え入れてCIを始めてみませんか？
Tweet