読者です 読者をやめる 読者になる 読者になる

ぺい

大阪の専門学生の落書き。主にエンジニア寄りの話。

テストコードが生む生産性について

テストコード書いてますか?!!!

最近になって、テストコードをちゃんと書くようになったぺいです。
今まで、どうしても以下のような理由でなかなか書けていませんでした。

  • どうやって書けばいいのか分からん。
  • 正直めんどい。

何故そんな私が、テストコード書くようになったのかについて、実経験を元にまとめてみました。

テスト書かないと起きる問題

自分はまだ学生ですが、アルバイトなどでプロダクトコードを書く機会があります。そこでテストを書いていないことによって起きた問題がありました。
それは、大きな変更が怖くて出来ない事と、動作チェックを手作業で行うので、チェック漏れはもちろん時間もかかるという2点です。

大きな変更が怖くて出来ない

例えば、様々な箇所から参照されているプロパティやメソッドの変更があったとします。その変更をすることは容易ですが、その変更から生じる影響範囲が広ければ広いほど、絶対に大丈夫という担保が難しくなります。そのため、問題っちゃ問題だけど、思い切って直すまでもないなというものは放置してしまう。
しかし、これが絶対に必要な変更だった場合が最悪です。かなり危険な上に、精神衛生上よろしくない開発がスタートします。もし、テストをちゃんと書いていれば、変更によって生じる問題が分かるので、変更に対して億劫にならずに済み、改善もスムーズに出来るので、最終的にサービスの寿命も生産性も上がると感じました。

手作業チェックはテストコード作成より時間がかかる

テストコードを書かない場合、コードの安全性は手作業によって行われます。なので、当然のように抜けもあります。しかも、チェックがその時の一回しか行われないので、後からの仕様変更でバグが発生しても、気がつかないことがほとんどです。結局そのバグのせいで余計な業務が発生して、テスト書く時間以上の時間がかかっていたりして、かなり悲惨な状態になっていたりする。
また、出来上がったコードのチェックがそもそも面倒なので、コードチェックは後回しになることが多く永遠チェックされないまま放置されたりしていることもある。

結論

テストは書かなくてもプロダクトは作れますが、長く運用する程、問題が発生します。結局テストコードを余裕で書ける時間以上の時間を食われるので、無理してでも書いた方が良いと結論づき、書くようになりましたとさ。

github.com 余談になりますが、BDDというテスト手法がわりと自分の中で良いなと感じいます。