ユニットテストを書いてみよう -

こんにちは、あのぶるです。ユニットテスト、書いたことありますか？
もしプログラミングを勉強し始めたばかりであったり、自分ひとりで開発をしている場合、「書いた方がいい」と言われても良さがいまいちピンと来ないかもしれません。そうでなくても書いたことが無ければ「手間が増えるのでは？」と感じているかもしれません。私もユニットテストを初めて書いた頃はそう思っていました。今回はそんな「ユニットテスト」についてお話をしようと思います。
……とは言え、すでにたくさんの人たちによってユニットテストの重要性やメリットを解説する素晴らしい文章がたくさん書かれていますので、今更私が語るのも、とも感じています。ですので、今回はそれらに触れるきっかけとなれるように頑張ってみます！

ユニットテストとは？

「ユニットテスト(単体テスト)」という言葉自体はその名の示すとおり、1つのユニットに焦点を当てて行うテストのことを言います。その「ユニット」とは何か、というのを定義するのはちょっと難しいのですが、関数やメソッド単位であったり、画面上のボタンや入力項目単位であったり、状況によってさまざまです。
手作業で人の目を使って確認することもありますし、テスティングフレームワーク(具体的な名前はプログラミング言語によってさまざまですが、主に「○○Unit」という名前の付いたツール、総称してxUnitと呼ばれたりもします)を使い、検証したい内容をコードで表現して、そのプログラムを実行して検証することもあります。

あくまで個人的に見聞きした範囲においてですが、最近は「”ユニット”テスト」と呼ぶ場合、テスティングフレームワークを使って自動化したものを指すことが多いのかなと思っています。少なくとも、「(ユニットテストを)書く」という表現が使われていれば、自動化したテストについて述べられているものと判断して良いかなと思います。
今回言及するユニットテストも、テスティングフレームワークを使ったテストについてお話をしていきたいと考えています。

なぜユニットテストを書くのか

簡単に言うと、書いたプログラムが意図通りに動くことを、自動的に、短時間で、何度でも確認出来るようにするためです。プログラムを書き始めた当初は全体を見て正しさを判断することも簡単にできますが、開発が進むにつれてコードのサイズは(たとえ一つ一つのモジュールは適切なサイズに分割されていたとしても)どんどん大きくなっています。それなりの規模のソフトウェアであれば、簡単に万単位の行数になるでしょう。それほどのコードがあれば、ちょっとした仕様変更であっても影響範囲を慎重に見極めないと思わぬトラブルを招くことになります。直すたびにプログラム全体をテスト出来ればそれが一番なのですが、手作業でテストする場合はそれも非常に困難な作業になりそうです。

ユニットテストは一度書いてしまえば、後はコマンドを一つ実行するだけで何度でも同じ確認が出来るようになります。テストにかかる時間も、手作業で同じことをするのに比べれば圧倒的に早く済ませることが出来ます。
また、環境を整えてコマンドを実行すれば良いということは、さまざまなタイミングでテストを組み込めることも意味します。例えばOSSのプルリクエストに、自動テストの結果が通知されているのを見かけることも多いのではないでしょうか。顔を合わせて作業することが出来ないOSS開発においても、そのような通知があれば動作検証が出来ているかどうかが一目で分かるため、プルリクエストに対する議論がスムーズに進みそうです。

また、よく言われる副次的な効果として「ユニットテストを見れば、そのメソッドをどう使えばいいのかを知るドキュメントの代わりになる」というのもあります。丁寧にテストが書かれたOSSであればレアケースでどう動作するかも確認出来るので、覚えておくと意外と役に立ちますよ。

テストコードを書くの面倒じゃない？間違えない？

正直なところ、慣れるまでは面倒に感じることも多かったです。でも、テストがあることによってその後の追加作業に対して「テストが通ってるからまずは大丈夫」という安心感を得られることは本当に心強いです。これはしっかり運用出来てこそ得られるものなので、ちょっと大変でも、まずは一歩踏み出してみて欲しいなと思っています。

それからよく聞く心配事として「テストが間違っていたらプログラムが間違っていることに気付かないのではないか」という話があります。作業の過程でテストコードを間違えること自体は、人間が書くものなので当然起こりうると思います。ただ、正しくユニットテストを使いこなすことが出来るようになれば、それが最終的なリリース物に対して影響を及ぼす可能性についてはあまり心配する必要がないとも思っています。
これも個人の経験ベースでの話にはなるのですが、おそらくユニットテストを間違えたまま開発を進めてしまうことが起こりうるのは「そもそも仕様理解が誤っている場合」か「とにかくテストが成功するように、場当たり的にテストコードやプロダクトコード(実際にソフトウェアの一部としてリリース対象となるコードのこと)を修正してしまった場合」のいずれかであることがほとんどでした。仕様理解が誤っているのであればそれはもうレビューなどで他の人に指摘してもらうしかないですし、後者については場当たり的に対応するのではなく、落ち着いてどのように動作するのが正解かを読み解いていくのがやっぱり大事ということになります。ですから、プロダクトコードと一緒で分かりやすいテストを書くことも大事なことなのです。
ちょっとした修正でバタバタとテストが失敗する光景を見ると怖くなりますが、これこそ「見落としていた影響箇所を発見できた」という自動化したユニットテストの恩恵です。それに、何だか分からないものをリリースする方がもっと怖いですしね。

TDDを学んでみよう！

ちょっとコードを書く手数を増やすことで、その後の圧倒的な安心感を得られるユニットテスト。それを足がかりにしてソフトウェア開発をする手法としてTDD(Test Driven Development: テスト駆動開発)というものがあります。
詳しい話については各地で開催されているTDDBC(TDD Boot Camp)で、和田卓人さんに基調講演の動画があります。和田さんはテスト駆動開発という本の翻訳者でもあり、「TDDの伝道師」の異名を持つ、日本国内におけるTDDの第一人者とも言える存在です。
私が実際に過去のイベントに参加したときは、お話を聞いて「テストを書いてみたい！」という気持ちが盛り上がったことをよく覚えています。是非一度ご覧になってみて欲しいなと思います。