JavaScriptのテストを開発工数に入れてもらうには？：UXClip（28）（2/2 ページ）

» 2013年05月08日 18時13分公開

[佐藤翔，ねこポッポ]

JavaScriptテストフレームワークの比較

　TISの佐伯純氏は、QUnit、Mochaなど各JavaScriptテストフレームワークとJsTestDriver、Karma＋アルファの便利なツールを紹介した。Capybara-webkitとCucumberを組み合わせることで、ユーザーの受け入れテストを自動で実行する方法も紹介した。

　フレームーワーク選択時に考えるポイントも語った。まずは自分たちが作るものはどのようなプロダクトやサービスなのかを良く考える。そして開発スタイル（「TDDかBDDか？」「メンバーは？」「自動化は？」など）を決めた後で、テストツールを選択する。「プロダクト自体や開発の持続性・継続性を支えるもの」という意識でテストツールは選択されるべきと述べた。しかし、「どのツールも似たような機能を持っていて、選択しづらいかもしれない」と述べ、「最終的には開発者たちが自分たちの開発リズムを保ち、心地良く開発ができるツールを選んで良い」と締めくくった。

セッションのスライド

現場でテストはどう行われている？

　イベントの後半には、セッションを行った4人による座談会が開かれた。その一部を紹介する。

テストをテスト未経験者に取り入れてもらうためには？

佐伯氏：自分自身の経験を語ると、私は新人の時からチームに放り込まれてペアプログラミング（以下、ペアプロ）をしていて、「お前はテストを書かなきゃいけないんだ」という状況に最初からありました。トレーニングでしたね。それが当たり前なのだと刷り込まれていました。また、うちの会社の場合、開発標準を最初に決める際に、テストを行うと明記したら必ずやらなければいけない、そういう状況で覚えていきました。

斎藤氏：私は、「テスト自体が楽しそうだ」というところからスタートしました。楽しさを感じてもらいながら、「テストはコードを書く上で大切なプロセスである」ことをどう伝えれば良いのかを考えています。佐伯さんと同様にペアプロを通して、目の前でテストの利益が見えてくるのは楽しいですし、赤を緑にしたくなるというゲーム性もあります。そういうテストの面白さを一緒に見ていくのが良いかと思います。

佐藤氏：フロントが得意なメンバーが、まずテストのスケルトンというか、それを生成する簡単なスクリプトを書いてくれました。「そのスクリプトにこのファイルのテストを作ってくれ」とお願いをすると、そのファイルのクラスのコンストラクタのテストまでやってくれるものを作ってくれました。コンストラクタを呼んでエラーにならないところまで1つ目のテストができる状態です。「まずテストを一個も追加しなくて良いからコンストラクタのテストだけでも書いて」というのが初めの一歩としては良くて、現在、少しずつ社内で広まっている状況です。

外村氏：周りのテストができる人に教えてもらったり環境を作ってもらったり、あるいはやらざるを得ない状況になることが自然なのかもしれませんが、そういう環境はなく、テストを書いてみたいという人も多いと思います。最初はつまずく可能性が高いので、いきなり自分の携わっているサイトのプロジェクトでやるのではなく、ちょっとしたライブラリのようなものを作り、それに対しテストを書くのが簡単で良いかもしれません。

テストを書いていてよかったと思うエピソード

佐藤氏：テストが書いてある状態のコードならリファクタリングから始められるという点が精神衛生上良いですね。嬉しいですね。

斎藤氏：コードの書き出しで苦しむことがあると思いますが、まずテストを書くことで滑り出しが楽になります。セッションでも話しましたが、私はもともとロジックをアウトライン化したものをコード上に書く習慣があったんですが、それがテストに置き換わりました。自分のワークスタイルに合っています。

佐伯氏：特に途中から任せられる場合ですね。まず実装を見るんじゃなくてテストを見る。そこから仕様を把握できますね。

外村氏：私は1年前に自分が書いたコードを見て、テストを書いておいて良かったなと思いました。1年前の俺ナイスって思いました（笑）。

　参加者からの「テストを工数に入れてもらうには？」と質問には以下のように答えてくれた。

佐藤氏：あらかじめ多めに取ることですね（笑）。多めに、というのは悪い意味ではなくて、コードをこの品質で書くためにはこれだけやる必要があり、これだけの工数が必要である、と合意を取っていくということです。「テストを書くから」とか「この機能を作るためにリファクタリングをする必要が……」と細かいことを技術側ではない人に伝えると、「そんなのはいいからとりあえずこの機能だけをお願い」とお願いされがちです。

佐伯氏：すべてきちんと説明するのが良いですね。開発し保守をする、そのためにテストをコードで書いて置いておくのが一番良いですと伝える。コストも抑えられますと。その上でこれだけ工数が必要であると示し納得してもらった、というエピソードがあります。ただ、実際にはこっそり（笑）……こっそりとはうまくいかないんですけど、一行ピッとテストについて記載しておくというのが良くあるパターンですね。

外村氏：3カ月くらいと見積もった案件でテストを書かなかった場合、最終的にバグが発見され4カ月くらい掛かってしまったということがあります。最初から品質保証という形でテストの工数を取っておくのが自然かと思います。