第8回　UnitTestをする理由(再び) - テスト講座

変更を恐れるな

開発者の中で以前からよく次のような言葉が言われます。

ちゃんと動いてるんだからその部分は触るな

これはある意味正しいのですが、しかしそれを続けていくと何かがあったときにも触れないモノになっていき、いつかはバグを生み出す部分となっていく可能性を秘めています。

自分の開発しているコードに対して、テストを書いたり、コメントを書いたり、ドキュメントを書いたりして、どのような仕様になっているかを残しておく努力をしましょう。これもよく言われることですが、「数ヶ月後の自分は他人」です。誰かのためではなく自分のためにテストコードを書く習慣をつけていきましょう。

"きれいで動作するコード"を目指そう

我々開発者が目指すべきコードは"きれいで動作するコード"です。これは何を表しているかというと、コードには"きれい/汚い"・"動作する/動作しない"の2×2の状態があるということであり、最終的には"きれいでかつ、動作するコード"を目指さなければなりません。

とは言っても一足飛びにそこには辿り着けません。前回と今回でやったものというのは次のようなサイクルを辿っていたことになります。

• (1) 最初テストだけを書く。これはまだ"動作しない"。これは「このように動作して欲しい」という仕様を書いているということでもある。
• (2) とりあえず"動作する"ようにする。しかしまだ"汚い"。
• (3) さらにテストを追加する。また"動作しない"状態になる。
• (4) "動作する"ようにコードを修正する。
• (5) "動作する"ようになったコードを少し洗練させる。これで少し"きれい"になる。
• (6) このサイクルを繰り返して"きれいで動作するコード"にしていく。

今回の例でいえば最後に正規表現をひとまとめにするというのが(5)の部分にあたります。テストコードがあれば、洗練するときにコードを少々大胆に変えても安心です。なぜかといえば間違った修正をすれば今まで書いてきたテストコードが間違いを指摘してくれるからです。

どうですか? テストコードのある開発スタイルが楽しそうなものに見えてきませんか?

今回のまとめ

• バグがあったときにはそのバグのパターンをテストとして追加して対応する。
• 仕様変更があった場合もテストを追加して対応する。
• テストコードが増えるとその後の修正は安心して行える。テストが機能追加/修正をする勇気を与えてくれる。
• 最終的に目指すべきは"きれいで動作するコード"である。

最後に

8回に渡ってテストについて解説してきましたがいかがだったでしょうか? 今まで他人事であったり、やらされていると感じていたものが身近なものとして感じられたり、やってみようと思われましたでしょうか?

実際にやってみると、まだまだ準備されているツールがかゆいところに手が届かないものであったり、時間に追われておろそかになったりと色々壁にぶつかります。しかし、テストを行うことは最終的には自分の利益になるものです。

少しずつでもいいので、テストと共にある開発スタイルに移行してみてください。世界が少し変わるかもしれませんよ。