テストコードといえば、テストコードが必要か必要でないかというのはちょいちょい議論になるものではありますが、個人的には正しい開発を行う上では必ず必要になってくるものだと思っています。
唐突に自分の意見を書いてみましたが、
「じゃあなんで、テストコードを書くの???」
と聞かれるといくつかのメリットをあげることはできると思いますが、テストコードのない現場の忙しい開発者たちを相手にテストコード導入のメリットをあげて説得できるかというところにあまり自信が持てなかったのでテストコードを書くメリットを自分なりに整理してみました。
当たり前だけどプログラムがちゃんと動いているかを効率的にチェックできる
これは、まあ当たり前というかこれが達成されていなかったらテストコードのある意味がないですよね。
ただ現在のシステムで、作った後に手を加えないシステムというのはほぼないわけで、日々訪れる仕様変更や機能改善のためになんどもコードが書き換えられていきます。また、コードというのは保守期間やシステムの年齢に対して増大して行く傾向にあるので、最初は少人数でも品質を担保できていたコードがどんどん大きく複雑になり管理が難しくなってきます。
そんななかで、GUIベースでの統合的なテストとはいわずともモジュールレベルで仕様通り動作しているかどうかをきっちり担保できていると日々の開発を進める上で大変心強いです。
サーバーから意図しないレスポンスが返ってくるのでみてみたところ、既存のバグでそれの調査と修正で予定した多くの工数をとられて、当初の見積もりをオーバーするとかいうのって本当にイライラしますよね。既存のコードが正しく動いていること(完璧にというのはなかな難しいですが)を担保できていない中での開発というのは非常にストレスがたまりますよね。
日々の開発を行なっている上で既存のバグが三つも四つも見つかるような現場ではテストコードの導入をオススメします。
デプロイ作業が自動化できる
これはシステムの品質というより作業工数の効率化観点ですが、テストコードである程度のカバレッジがないと自動デプロイって怖くてできないですよ。
静的型付けの言語とかであればよいですが、rubyやphpなど実際に動かしてみるまで構文エラーとかをすくえない言語では、本番でundefinedエラーなどのしょうもないエラーが起きてしまうのは嫌ですよね。テストコードで8割程度のカバレッジをもっておけば、デプロイの前に自動でテストが回るようにしてテストを通過した場合だけデプロイするという形でしょうもないエラーの多くを防ぐことができます。
テストがない状態でもデプロイの自動化はできますが、ちょっと怖くてできないですよね。。テストコードのないプロジェクトはこのように開発の運用にも影響を与えるので、きっちりテストを書く習慣をつけておきたいです。
バージョンアップが楽になる
テストコードがあるとバージョンアップが楽になります。バージョンアップする前には前バージョンとの変更点を確認して、修正してという流れになると思いますが、漏れとか怖いのでひとつずつ確認していきますよね。
そんな時にテストコードがあると完璧とはいかないまでも、人の打鍵では確認しづらい細かい部分までコードがバージョンアップの影響を受けていないか確認することができます。
まだ生まれたばかりのライブラリとかを使っていると結構バージョンアップの頻度が高く追従するのが難しかったりしますよね。かといって、古くなってしまったシステムをメンテナンスするのも嫌ですし、、、
テストコードを日頃から書いておくとバージョンアップする際には必ずテストコードのありがたみを感じることができるので、必ず報われることを信じながらテストコードを書いていきましょう。
エンジニアとして一定の評価をされる
フリーランスの面接でも割ともともとの現場のカバレッジを聞かれたりしたのですが、外からのみられ方としてテストコードがかける人なのか、テストコードを書く意義をわかっているかどうかというのはみられているように思います。
知り合いのフリーランスの方でも現場に入る前にそのプロジェクトのコードカバレッジがどれくらいか聞くそうです。テストコードのない現場だと、こっち直したらあっちが壊れてとかいうなかなか辛い状態での開発になるのでそういうのを警戒してあらかじめ開発環境が整っている環境かどうかというのは働く先での評価の基準になるようです。
転職の面接の際にも前職ではCIを導入していて、マスタマージと共に自動デプロイが走っていましたとかいうと「ちゃんとした現場で開発してきているな」という評価にはなると思います。
「テストコード0の現場からカバレッジを8割にしてCI環境を整備しました!」というほどでなくても、一エンジニアとしてテストコードをかける、書いた経験があるというのは非常に大事なことのように思います。
コードがきれいになる
テストコードを書いてみるとわかるのですが、コードにはテストの書きやすいコードと書きにくいコードが存在します。当然テストコードを書きやすいコードの方が好ましいわけですが、テストコードの書きにくいコードというのはだいたい一つのクラスやメソッド多くのことをやりすぎているコードです。
一つのメソッドであまりに多くのことをやろうとすると、人間の理解力を超越してコードを読むのが難しくなりますし、他のクラスへの依存も高まったり、重複の多いコードになりがちです。
これを防ぐために、テストの書きやすいコードを意識しながらコードを書くことができると単一責務を守った綺麗なコードができあがります。
テストの書きやすいコードというのが、自分でテストコードを書いていないと感覚がわかりづらいので、普段テストコードの書いていない人は今すぐにでもテストコードを書く習慣をつけられると良いと思います。
リファクタしやすくなり、コードの質を保つ好循環が生まれる
テストコードがあることによって既存のコードに手を入れてもテストコードがしっかり書いてあれば、自分では気づけない部分でテストがこけてくれて「あ、こっちも直さないといけないのか」となるので、リファクタ作業をするときも安心して作業をすすめることができます。
システム開発を進めているとどうしても納期に追われたりしてコードが汚くなっていきがちなのですが、テストコードがあるとリファクタへの心理的ハードルが下がるので、機能改修のついでのファクタなどができるようになってきて自然とシステム全体でのコードの質が保たれます。
ひとつずつテストコードを書いて行くの決して簡単な作業ではありませんが、ある程度カバレッジがあがってると上記のような好循環が作れるので、ぜひともテストコードの導入をオススメします。
自分の書いたコードを見直す時間が作れる
これは最近感じたのですが、テストコードを書く時というのは、プロダクトのコードをみながらコードを書いて行くので、自分の書いたコードをレビューしているよう状態になります。
自分で書いたコードって時間を置いてみると
「なんで、こんな酷いコードかいているんだろう??」
と思うことありますよね。普段自分で仕事をしていて自分のコードを見直すことって意外となくて3ヶ月後とか半年後に同じ箇所に戻ってきて過去の自分の書いたコードで自己嫌悪に陥ったりするのですが、テストコードを書くことによってこれが短いスパンでできるようになります。
短いスパンで自分の過ちに気付けるので、次からコードを書く時にそこを気にしながら書くことができます。
これは自分がまだ未熟だからかもしれないのですが、コードって一発できれいなコードをかけるということが少なくて、一つの機能改善の中でも一度書いたものに納得がいかず再度書き直すなんてこともよくあります。
個人的には最初に書いたコードってどこか無駄があるので、それをまた書き直していくことでシンプルで無駄のないコードができあがると思っているので、書き直せば書き直すほど無駄のない筋肉質なシステムができあがるとも思っています。
なので、ひとつの開発の中で、
- 一旦動く形でコードを書いてみる
- 無駄な部分をリファクタする
- テストコードを書きながら再度コードの見直し
- 納品物としてテストコードときれいに整頓されたシンプルなコードができる
まとめ
以上私の考えるテストコードを書くメリットのまとめでした。
- 当たり前かもしれないが、コードの挙動を効率的に確認することができる
- デプロイ作業が自動化できる
- バージョンアップが楽になる
- エンジニアとして評価される
- コードが綺麗になる
- リファクタしやすくなり、コードの質を保つ好循環が生まれる
- 自分のかいたコードを見直す時間がつくれる
まとめてみると、テストコードは現場的にデプロイの自動化で工数の削減ができたり、コードの質を担保できたりというチームよりなメリットもありますが、きれいなコードをかけるようになるとか自分の書いたコードを見直す時間が作れる、エンジニアとして評価されるなど個人的なメリットもあります。
テストコードに関しては、TDDだったら〜とかBDDだったら〜とか色々あるのかもしれませんが現時点個人的に感じているテストコードのメリットをまとめてみました。