こんにちは。製品企画室の土井です。
突然ですが、こちらの記事を覚えていますでしょうか?
実装したアプリケーションの動作確認を「テストコード」と呼ばれるテスト専用のプログラムで行ってしまおうというお話です。TOPSIC開発では、「Rspec」と呼ばれるRuby言語のソースコードをテストするためのツールを使用しています。定期的にテストコードを作っておいたほうがよいのは分かっていますが、最近は新機能開発や障害修正に夢中になっており、あまりテストコードを書いていませんでした。ですが、つい先日、過去に自分で書いたテストコードに救われるという出来事に遭遇しました。
過去の自分からのメッセージ
その日、私はいつも通り追加機能の実装に取り組んでいました。おおよその実装を終わらせ、リンタ―で構文チェックを済ませました。「リンター」とは、インデントの有無や条件分岐の複雑度などをチェックし、読みやすいコードになっているかを自動で確認してくれるものです。そして、プルリクエストを作成するために、Githubに実装したソースコードをpushしました。CircleCIのチェックが全て通ったら、確認してもらおうと思ったそのときでした。
CircleCIのチェックが失敗していました。
リンタ―チェックで失敗するのはよくあるパターンです。ですが、今回はローカル環境で確認を行ってからGithubにpushしたため、リンタ―チェックが失敗するはずはありません。どこで問題が起きたのか? 調べてみると、Rspec(テストコード)が失敗していました。追加機能を実装した際に、一部に追加漏れがあり、もともとあったページが上手く表示できなくってしまっていたのです。しかも、このテストコードは、私がRspecを勉強しはじめたときに、初めて書いたものでした。追加実装した部分ではなく、既存の部分が動かなくなっていたため、動作確認で今回の修正漏れを見つけるのはなかなか難しかったと思います。
まだ右も左も分からず、いろいろ調べながらテストコードを書いていた頃の自分が、今の自分にソースコードの修正漏れを教えてくれました。
やっぱりテストコードは書いたほうがよい
今まで、Rspecで修正ミスが発覚するという機会がありませんでしたが、いざそういった場面に直面してみると、テストコードがいかに便利なものか思い知らされました。私がチームに配属されてから、半年ほどが経ちましたが、その間にも新機能がたくさん追加されました。追加実装をするたびに、関係のありそうな既存の機能を全て確認するのは非常に面倒です。最近、テストコードの実装がおろそかになっていた私ですが、今後は追加実装の際にテストコードも一緒に準備していくよう心掛けたいと思います。
