TDD の話

Podcastを聞いてて、これは読み返せる形に残したいと思ったので、この記事を書きました。

ネタ元

• Qiita FM エンジニアのキャリアを深堀り
  「#18 テストの意味と TDD の役割」
  ゲスト：t-wada さんこと 和田卓人さん

概要

テストを書いているのに効果的じゃない？！

• 「なぜテストを書くのか？」「どういった書き方が効果的なのか？」が腹落ちしていない

変化を支えないテスト?!

• 機能追加、バグ修正、アーキテクチャを変化させるときに、既存のテストが支えにならない

変化を支えないテスト①

• 不安定なテスト
  • 遅い
  • よく失敗する
  • 実装は悪くない

変化を支えないテスト②

• 粒度の細かいユニットテスト
  • 実装の詳細に対して網羅的に書かれているが、実装に対して構造的な結合度が高い
  • 実装を変えるとしょっちゅうテストが壊れる
  • 壊れているテストを見てみると、実装の内部深くのプライベートメソッドをテストしていたり、内部変数をみている
  • 外部からのふるまいは変わらないはずなのに、内部の実装をちょっと変えただけですぐに失敗する、脆いテスト
  • 設計の可動域が狭すぎる

テストの信頼性

• テストの成功、失敗、のどちらも信じられること
  • 下記の２択に判断が収束する
    • テストが成功したら、デプロイできる
    • テストが失敗したら、コードのどこかに原因がある

負のループ

• テストが不安定だからリトライしよう、みたいにテストが不安定であることが常態化している
• 実装を触るとテストがすぐ壊れるからあまり設計変更しないようにしよう、既存のテストを活かしながら開発しよう
• 新しく開発したときでも、今ある自動テストのやり方を基本的に真似してしまうので、設計変更の役に立たないびっしりと網羅的に書かれた構造的結合度の高いユニットテストが書かれていて、開発の邪魔になっているにも関わらず、新たに書かれたコードに対してもやっぱり同じような構造的結合度のテストを書いてしまう

コードの内部品質

• あるタイミングで「上げるぞ」と決意しないと、基本的には上がらない、ジワジワ下がっていくもの

現場あるある

• 基本的にコードの編集は、だいたい既存のコードを真似してコピー＆ペースとしてちょっと直して、みたいな形のことが続いていく
• しかもこれがよかれと思って行われている
• 例えば本当はもうちょっと中くらいの修正をしたほうが全体として良い状態になる、重複が少ない状態になるけど、GitHubのブラウザ上でコードレビューをやりすくするためにdiffを小さくして、diffを小さくするために小さなif文の追加だけで留めるだけにしよう
• よかれと思って小さな変更を行うっていうのが、ちょっと視点を引いてみると、全体の複雑性をジワジワ上げ続けている、つまり保守性を下げ続けている
• よかれと思って、新しく追加された小さなif文にびっちりと密着したテストを書いてしまう、そうするとその設計が固着化してしまう
• 本当はもっとリファクタしてそのif文自体をなくすべきなのに、if文をなくすとテストが壊れる
• だんだんよかれと思って小さな変更をして、よかれと思ってびっしりユニットテストを書いて、その保守性よくよく一歩引いて見てみると、保守性が低い状態がずっと維持されている

ソフトウェアはやわらかい

• ソフトウェアは変化しないといけない
• ソフトウェアは変更に対してやわらかい
• ソフトウェアエンジニアとして働くとは、常に不確実なものと戦うこと
• 「良いものを作れば形を変えなくてすむ」ではなくて、「形を変えられるものがよいもの」

自動テスト

• 変化を安全に素早くやるために自動テストで支える
• 形を変えられる自動テスト、実装に対して結合度が低い、インテグレーションテスト、E2Eテストだけでは変更を支えるテストにはならない
• インテグレーションテスト、E2Eテスト、ユニットテストをバランスよく配分することで、素早く自信のある変化を支える開発をすることができる

感想

個人的にこの回はささった。
それは、日々TDDで開発はしているものの、ユニットテストの粒度が細かすぎないか不安になるときがあるから。
ユニットテストの流派的にはロンドン派と呼ばれる方で書いているので、デトロイト派に比べたら構造的結合度の高いユニットテストになりがちなのかもしれない。
それでもできるだけ入力と出力に目を向けて、実装の中身は気にしない書き方を心がけているつもりでいる。
無理解でとりあえずTDDをしているだけでは自然とよい設計に導かれるわけもなく(多少は寄せれると思うけど)、「どういった書き方が効果的なのか？」というところは常に意識して学んでいく必要があると改めて感じさせられた。また、よい設計とは何なのかとか、どういうリファクタリングができそうかといったところの引き出しがあると、さらに自信の持てるコードが書けそうと感じた。