アドベンチャーアドベントカレンダー2022の19日目の記事です。
おまえ誰やねん
株式会社アドベンチャーでサーバーサイドのエンジニアをしている者です。
新卒でエンジニアとして仕事をし始め、2022年4月から、エンジニア3年目の節目に入社しました。日々勉強をしながら、いつの日か強いエンジニアになれる日を夢見て日々仕事をしてます。
どんな記事か
アドベンチャーに入社してからエンジニア人生で初めてテストコードを書く機会に恵まれました。前の会社ではデバッグ業務をやっていたことはあったのですが、テストコードを書いたことがなく、「どういう観点でテストをするべきなのか」「そもそもテストコードの書き方もわからん」みたいな状態でした。テストコードに関して何もわからない状態でしたが、実際に書いてみるとめちゃめちゃ便利でした。
この記事では「テストコードってこういうところが便利だよ！」 という話を、まだテストに詳しくない人にも伝わるように話して行きます。
「テストコードかくあるべし」「こういう書き方の方がベター」みたいなテクニカルな話というよりかは、「確かにそれは便利！」「同じ悩みを抱えていたけど、テストコードを書くことで解決するんだなぁ」みたいな直感的に伝わる話をしていきます。
便利だと感じたこと
リファクタしやすい
ビジネスロジックに修正が必要なことが多々あると思います。テストコードがないと、どこまで影響範囲があるか分からず、ビクビクしながら修正・確認をしたことがある人も多いと思います。
もしビジネスロジックに修正があっても、テストコードがあれば予期せぬバグやデグレを事前に検知することができ、安心感を持って修正やリファクタを行うことができると感じました。
設計書になる
実際にコードを書く前に先にテストコードを書いておくことで、そのテストコードが設計書の役割を果たすことになります。（TDDの考え方かも）
テストコードにそのロジックの正しい振る舞い、間違った振る舞いが記載されているので、数ヶ月後の自分や他のエンジニアがそのロジックを修正することになっても、テストコードを確認すれば、そのロジックの正解・不正解を確認することができます。
実装に気を配るようになる
テストコードを書くことを前提にしていると、実装にも気をつけてコードを書くようになります。
テストパターンが増えないようになるべくシンプルに書いたり、if文やswitch文などの分岐をなるべく使用しないようにしてみたり。
テストコードを理解することで、より良いコードを書くことにつながるのではと感じました。
気をつけたいこと
無意識に都合のいいテストを書かないこと
ロジックを実装した本人がテストコードを書くと、そのロジックについてよく知っているため、無意識にパスしやすいテストコードを書く傾向があるかなと感じました。
実装をする前に先に最低限のテストコードを書くなどして、なるべくフラットな状態で書くことで防げるかと思います。
テストコードを過信しすぎないこと
テストコードは結局のところ、想定できるエラーを検知するための仕組みでしかないと考えています。
動かしてみるまでは、そのコードが本当に正しいのかは分からないと思っていますし、もしかしたら想定していないバグやデグレが発生する可能性もあります。
テストコードだけではなく、システムテストや受け入れテストも必要です。
あくまでも、実装したコードを「正しいと思われる状態」に近づけるためのツールだと考えておくことも大事かなと思います。
まとめ
自分自身、テストコードを書くまではその必要性を感じていませんでしたが実際に書いてみて多くのメリットを感じました。
この記事が読んでくださった方の参考になれば幸いです。