最近、新卒エンジニアと1〜2週に1度の頻度で1時間ほどペアプロを行っています。
新卒君の技術力の向上と作業効率のアップを目的として行っているんですが、
これがなかなか効果ありで結構楽しいです。教えることで自分の知識の再確認にもなっています。
で、先日はPHPのテストコード作成に取り組むことに。
PHPUnitでテストコードの作成に着手したわけなのですが、そのとき新卒君にこんなことを言われました。
「なんでモデルのテストコード書くんですか？コントローラの200テストだけで十分じゃないですか？」
時間がなかったため、
「モデルのテストも書いたほうが、バグの発生率は減らせるでしょう？」
とだけ答えました。
我ながら雑な答え方だし、そもそもテストコードを何故書くべきなのかちゃんと教えたほうが良いなぁと思ったので文章として残すことにしました。
良いコードを書く意識が自然と身につく
テストコードを書くのが習慣的になっていると、必然的にテストしやすい構造のプログラムを書くようになります。
つまりどういうことかというと、複雑なメソッドを書くことが減り、疎結合で副作用の少ない小さな機能単位で開発するようになるのです。
テストしづらい構造のプログラム…極端な例ですが、例えば1000行くらいあってスパゲッティなメソッドは、非常にテストしづらいというのは容易に想像できると思います。
そんなスパゲッティなコードに対して、テストコードが仮に存在していたとしても、少しの変更を加えたいと思ったら途端にテストコードのメンテナンスコストは跳ね上がります。
「メンテナンスにコストがかかるならそもそもテストコード書かなければいいのでは？」
と思う人もいるかもしれません。
確かに重要な箇所でなければ時間がもったいないのでテストコードは書かなくても良いかもしれません。
しかし、決済機能など一歩間違えると死ねるような機能を拡張・修正しようといった場合、テストコードがあるのとないのではプロダクトコード自体のメンテナンス性が全く違ってきます。
テストコードがありテストしやすい構造にできていれば、ソースの見通しもよくなっているはずなので、作業のしやすさも変わってくるでしょう。
テストコードがないとリファクタリングと呼べない
「うわーなんだこのクソコード、リファクタリングしてやる！」
と思うこと、ありますよね。
でも、テストコードがある状態でリファクタリングするのと、ない状態でコードを改善するのではまったく違ってきます。
そもそもリファクタリングとは、外部的振る舞いを保ちつつ内部構造を改善することを指します。この外部的振る舞いをテストコードでチェックしてやるわけです。
そもそもテストコードが甘かったりバグってしまっていることもあるので、100%担保できるわけではありませんが、テストコードによって常に同じ外部的振る舞いをチェックできるため、コードを改善するつもりがデグレーションを起こしてしまうといった可能性は確実に減ります。
プログラムにできることはプログラムにやらせましょう。
最終的に作業時間が減る
テストコードも書けていいコードも書けていると、以下の理由により最終的には作業時間の短縮につながると考えられます。
- 読みやすいソースコード、設計になり機能追加・修正がしやすくなる
- テストで事前にバグの発見がしやすくなる。結果手戻りが減る
なので最初は手間でも、テストコードは積極的に書いておくのが良いと思います。
また上記にも書きましたが、バグがあると致命的な機能に関しては、厚めにテストケースを書いておいたほうが他のプログラマも幸せになるでしょう。
最後に
上記以外にも、テストコードのメリットについて書かれた記事がググればたくさん出て来るので、まだよくわからんって場合は調べてみてほしいです。
レガシーな開発環境でそもそもテストコードをどうやって書けばいいんだって場合は、レガシーコード改善ガイドなんかを読むと良いです。
(数年前に読んで内容忘れかけてるので僕も読み直したいと思います)
というわけで、僕ももっとテストコード書いたり良い設計に思いを馳せることにします。