テストコードを書くようになって感じたこと

TDD, テスト, マネージメント

この記事は最終更新日から1年以上が経過しています。

初めに

テストコードを書くようになって感じたことをまとめたいと思います。

結論

結論からいいますと下記のことを感じています。

  • 昔よりマシなクラス設計ができるようになった
  • テストコードがあると既存のコードにも手を入れやすい

昔よりマシなクラス設計ができるようになった

なんとなくそう感じるな。。というの深堀したところ、 ちょっとは単一責任の原則（SRP） の考えに沿って
クラス設計できるようになってきたのかな、というものでした。

「変更する理由が同じものは集める、変更する理由が違うものは分ける。」良いデザインの基本原則を1つあげるとすればこれでしょう。

きっかけは、privateメソッドに対してのテストコードを作成している時でした。

「privateメソッドのテストって書くのが面倒でやりたくないな」
「そもそもなぜprivateなのか。。」
↓
「なぜprivateな振る舞いをテストしたいんだろうか」
↓
「いろいろ設計間違えたかな。。」
↓
「SRP という考え方あるらしい」

privateな振る舞いをテストしたくなるような設計は、なんらかの問題があり、興味深い振る舞いが多数埋もれているという状態は、ほぼ間違いなくSRPに反しているみたいです。なので設計を見直しましょうという考え方です。

テストコードがあると既存のコードにも手を入れやすい

こちらは既存のIFの改修時にテストコードがあったおかげで、いろいろ手を入れやすかった！と率直に感じました。実装している段階で、テストコードがあればすぐに想定外のところに影響を及ぼしていることがわかりましたので。

感想

結局テストコードを書くようになっただけでは、「手戻りがなくなりました！」とか「工数削減になりました！」など、直接、数値的コストに結びつく効果は約束できるものではないと感じています。
(もちろん既存のコードを陳腐化させないように手を入れやすくなるとか、実装の段階で不具合に気づくなど、その他メリットは大いにあると思います)

だとしたら、時間を割いてまでテストを書くことによって得られたもの、エンジニアとして成長できたなと感じたものを深堀して伝えていけたらなっというのが今の正直な感想です。

この記事を書いた人

與儀 善之
與儀 善之
好きなアーティスト:L'Arc-en-Ciel

TDD, テスト, マネージメント