「テストを書く」という習慣について
プログラミングをするときテストを書くということをプログラマはする。あー、全員じゃない。趣味でも仕事でも「テストを書く手間を割くと生産性が落ちる」と強く思っている、もしくは、「テストまで頭が回らない」「テストを書くことについて意味や効用やその方法を理解していない、知らない」というプログラマ、それから、何十年もプログラミングしてきてテストなぞせずとも完璧なプロダクトを作れる人、こういったプログラマたちはテストを書かない、または、テストを書くことを断固拒んている。でも仕事でプログラミングをしている人のほとんどは、仮に経験年数が少なくても、テストを書く習慣を身に着けているはずだ。そう信じたい。
「テストはこう書くものだ」と頭ごなしに押し付けられて渋々テストを書いている人がもしいたら、そしてそのプログラマが「テストを書くのってつまらないなぁ、嫌だなぁ」と感じていたら、それはとても不幸なことだと思う。「テストはこう書くものだ」と口うるさく言っている人の威圧感がどんなか、とか、もっと言うと、そいつが言ってる内容そのものは実はどうでも良い。テストの「書き方」は様々なアプローチがあってどれもこれも一長一短だから「どれが正解」とは言えない。彼(または彼女)の主張の中で「正解」な部分は「テストを書け」と言っている部分だけだ。それ以外はオプションなんだ。ぶっちゃけ実際のテストコードは好きに書けばいいし、どんな書き方にどんなメリット・デメリットがあるか確認しながらいろいろ試してみると良い。そう、その試してみるというプロセスが良い、大事。
更に大事な点が2つある。こちらを見過ごさないでほしい。
1. テストを書くのは楽しい。
2. 「どうテストしようか？」と考えながらコードを書くことに意味がある。
1つ目に挙げたことは本当だ。テストを書くのは楽しい。そして創造的な作業だ。でもそれは2つ目に書いたことと結びつかなければ実感として現れてこない楽しさだと個人的に思う。プロダクトやサービスの実行コードを書く際に「今コード化しようとしているアイデア(ロジック、課題、タスク、TODO…)は、どうしたらうまくテスト可能な形で書けるだろうか？」と自問ながらコードの構成を考えること、そして、書いてみること。そうすることによって自然と、風通しがよく(専門用語で言うと「疎結合な」)、読みやすく(リーダブルな)、保守しやすい(メンテナブルな)方向にコードベース(プログラムコードの集まりをこう呼ぶ)が向かっていく。「自然と」という部分がすごく大事。トップダウンに、強制的に、まるでスパルタ教育のようにそういう方向に持っていくんじゃなくて、プログラマが自発的に自然と良いコードを書く方向へ歩み出す。これがテストを書く文化がもたらす最大の恩恵なんだと思う。
そしてもちろんテストを書く。こまめに書く。頻繁にテストを実行する。
ちゃんと動機と計画があって書くテストだから、失敗するか成功するかはただの結果であり、対話的なプログラミング作業の中に出現する言葉のひとつに過ぎない、と気づく。テストの結果やログは、自分のアイデアや考え方に対するコンピュータからのフィードバックだ。この自分の脳とコンピュータとの間のフィードバック・ループをくるくる回し、開発のリズム(グルーヴと言ってもいい)を感じながらコードを書いていく作業は、単に頭の中だけでじっと考え込んでいるよりずっと楽しい。そしてもちろん、誰かから指示された通りにロボットのようになって無機質にコードを書く作業なんかとは比べ物にならない。「そう言われてみると、テストを書く作業は創造的で生産的なんだ、とちょっと思えてきた」と感じてもらえたらこの投稿を書いた甲斐がある。うまくすれば、今までは写経のように地味で無意味で非生産的な作業だと思っていたものも、テストを書くという一コマを上手に組み込んで楽しいエクササイズに変えることだってできるかもしれない。
ー
自分の言いたいことは以上なので、ここから先はおまけ。
実際のテストの書き方とか、テストツールについて詳しいことは書かない、というか、書けない。情報が膨大すぎる。逆に、特定の領域に絞ってテストについて調べようと思えば、豊富に情報を手に入れることができるから、そこは安心してほしい。
各言語の入門書や公式ドキュメントなどを開けば「テスト」の章があるはずだ。今まで読んだことがなかったら読んでみていただきたい。
特定の分野のハウツーに限定して手法を紹介しているような本やサイトでは、テストはサンプルコードを長くしてしまうから省かれていることが多い。ここは注意が必要。そういう趣旨のサンプルコードを鵜呑みにして本番のコードベースに組み込んでしまうと痛い目を見ることがある。ここでもやはり「どうやったらテスト可能になるか？」と考えながらサンプルコード(の言いたいこと)を咀嚼・消化すること。このプロセスが開発をうまく進める鍵になるし、あなたの成長する糧になる。
ちなみにこの投稿で書いたことは別に僕独自のアイデアじゃなくて、主に次の2冊に書いてあることを日常のコーディングで実践してみての「感想」のようなものだ。
機会があれば読んでみてほしい。『達人プログラマー』のほうはつまみ読みするだけでも面白い。『テスト駆動開発』のほうはちょっと読むのに根気が要るかもしれない。
SN
この記事が気に入ったらサポートをしてみませんか？