初めてテストコードを書く方に向けて|新人プログラマー時代の自分に伝えたいこと

はじめに

この記事では、

僕の10年間現場でテストコードを書いて失敗してきた経験、

書籍・勉強会などを通じて学習した内容、

などを言語化して、




もし新人プログラマー時代の自分にテストコードについて伝えるとしたら??

というテーマでまとめてみました。




プログラマー歴も10年目に入り、

後輩プログラマーの教育も最近では依頼されることも多くなってきたので、

改めて自分が、

現場で大切にしている考え方や、

注意しているポイントについて言語化してみたので、

自分の後輩や新人プログラマーの方々の参考になればと思います。




テストコードはなぜ必要なのか??

まずはテストコードがなぜ必要なのか??

どういうテストコードが必要で逆に不要なのか??

について理解するところから始めましょう。




他の人が書いているからとか、

現場の開発ルールがとか、

ただそれだけの理由で無駄にテストコードを増やして

保守コストを上げてしまっていませんでしょうか??




質の良いテストコードとは何で、

どこに注意してテストコードを書けば良いのでしょうか??




このあたりを記事にまとめたのでご覧ください。

テストコードの必要性と質




テストコードを書くときに大切にしている考え方と気を付けるポイント

ここからは、

自分が現場で失敗してきた体験や

書籍や勉強会を通じて学んできたことをベースに




現場でテストコードを書く際に、

自分が大切にしている考え方や気をつけていることなどを紹介していきます。




質の高いテストコードを書くにはバランスを意識する

質の高いテストコードには以下4つの特徴を備えさせる必要があります。

  • リファクタリングへの耐性
  • 迅速なフィードバック
  • 退行に対する保護
  • 保守のしやすさ


この4つを1つのテストケースに全て完璧に備えさせることは不可能で、

逆にどれか1つでもゼロになってしまうと、

そのテストケースの価値もゼロになります。




その中で、どのようにバランスを取るのが良いか??

について記事にまとめたのでご覧ください。

テストコードに備えさせる4つの特徴とバランス〜テストコードのきほん〜




テスト対象を4つに分類して考える

テストコードを書くべきか??

逆に書かないべきか??

それとも、テスト対象のリファクタリングから行うべきか??




テストコードを書く前には、

テスト対象を分類してそれぞれに適切な対応をしていく必要があります。




例えばテスト対象の設計が悪いせいで、

テストが書きずらいのに、

テストコードを複雑にしてテストを行うようなことは避けるべきです。

この辺りについて記事にまとめたのでご覧ください。

テスト対象を分析して4つに分ける〜テストコードのきほん〜




テストコードで検証すべき箇所とすべきでない箇所

質の高いテストコードが備えるべき特徴の1つに

リファクタリングへの耐性があります。




テストコードを書く際、

退行に対する保護のみを気にして、

リファクタリングへの耐性が疎かになり、

保守開発のフェーズで、

リファクタリングをする際にテストコードが

嘘の警告をするようになる。

というケースを現場でよく見かけます。




嘘の警告を減らして、

リファクタリングへの耐性をテストコードに備えさせるには??

について記事にまとめたのでご覧ください。

検証する箇所としない箇所〜テストコードのきほん〜




テストコードでモックやスタブを利用する時の注意点

複雑な依存関係になるようなテスト対象をテストする際、

モックやスタブを利用します。




利用時の注意点を記事にまとめたのでご覧ください。

モックとスタブの注意点とポイント〜テストコードのきほん〜




今後現場での経験や学習を通じて得た知識は随時追加していきます!!!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください