TDD実践を経て変わったこと

Qiita × Uzabase Tech Meetup#1
技術講演②「TDD実践を経て変わったこと」
で発表した内容になります。

https://connpass.com/event/210103/

Transcript

1. TDD実践を経て 変わったこと
2. 私たち 鈴木 謙士 ・2015/07にユーザベースにJoin ・SPEEDA開発を中心に活動するソフトウェアエン ジニア ・猫とカレーが好き 橘内 孝幸 ・2015/08にユーザベースにJoin ・SPEEDA開発を中心に活動するソフトウェアエン ジニア ・DDDとGoが好き
3. 今日お話すること 1. TDDのゴール 2. 設計・実装における変化 3. テスト・実装に対する価値観、行動の変化 4. プログラミング以外の変化
4. TDDのゴール
5. 「動作するきれいなコード」
6. 設計・実装における変化
7. 設計の良し悪しの指標が変化 Before 1. 設計に対する良し悪しの判断が自己満足の域を出なかった 2. 悪い設計に気付くことなく、未来の誰かが損をしていた （過去の自分を殴りたい・・・） After 自分が書いたコードが良い設計なのか悪い設計なのか判断するとき、テスタビリティ (テスト容易 性)という指標が生まれた
8. テスタビリティが何故指標として役立つのか 1. テスタビリティが低い場合、様々な課題があることに気付いた a. 独立性が低い b. 密結合になりやすい c. 責務がバラけがち 2. 設計を議論する時に、テスタビリティの観点で話すことが出来る 3. テストがやり難いと感じたとき、設計を見直すことのできるチャンスだと捉えることができる
9. しくじりに「気づく」タイミングの変化 Before 書いたコードが実際使われる段階になってはじめてしくじっていることに気づく 完璧だな 実装するぞ しくじった…
10. しくじりに「気づく」タイミングの変化 様々なしくじり 1. 必要がなかった 1.1. 「今」必要ない 1.2. 未来永劫必要ない 2. そもそも使えない 2.1. 期待値に誤りがある 2.2. 他の部分と組み合わせられない 3. 使えるが、使いづらい
11. しくじりに「気づく」タイミングの変化 After テストを書いている段階でしくじりに気づく テスト書くぞ なんかおかしいぞ このコード、 ダメダメなのでは ・・・・・・
12. しくじりに「気づく」タイミングの変化 なぜテストを書いている段階で気づけるのか 1. 外側（実際に使う側）から内側に向かってテスト →実装を繰り返していくため、気づく気づか ない以前にそもそも使わないコードは生み出されづらい 2. 最初に期待値を考えてテストを書くことにより、期待値がコードレベルで明確になっている ため、使う段階になって期待と異なるということがない。 また、組み合わせ部分も先にテストに書くため、あとになって実は組み合わせられないとい うことがないし、先に気付くことができる 3. テスト自体がテストの書きづらさによって「設計が良くない」ことを教えてくれる
13. しくじりに「気づく」タイミングの変化 まとめ 以前は「想像」で実装を行い、その想像にあわせて想像通り動くテストを書いていたと言える。 想像が現実と一致していることもあったが、常にそうではなかった。 TDDは想像と現実のギャップを迅速に埋めてくれた。
14. 実装の仕方の変化 Before はじめから完成形を目指した実装をしていた。 実装が完全に終わってから、その実装を検証するようなテストを書いていた。 とりあえず実装する ぞ。それも全部だ！ 実装できたから テスト書こう
15. 実装の仕方の変化 テストは、実装が正しいことを検証するためのみ に存在していた。 後でテスト書くため、テストが実装に依存する。 結果として次のようなことが起きていた。 1. テスト自体が複雑になっていた 「検証のためだから許容しよう」と考えてしまっていた。 2. 余計な検証をしていた 例: 一つのテストケースにアサートが複数あり、一緒くたに様々な検証をしている。 3. 必要以上に実装してしまっていた なんとなく実装するとやってしまいがち。 （YAGNIはどこいったの？） なんとなく野菜を買ったけど、 こんなにいらなかった・・・
16. 実装の仕方の変化 他に考えられる問題 先に実装すると、検証しづらく怪しさを感じたとしても、これまでにかけたコストを無駄にしたくない という心理が働き、実装・設計を見直そうという意識になりづらい。 そのため、テストを通すためにトリッキーな方法をとったり、複雑性を許容してしまう。 また検証自体を目的とする場合、テストが独立していないことや過剰であることに気づきづらくな る。 なぜか実装コードが汚いは許せなくてもテストコードが汚いのは許容できてしまってたりする。
17. 実装の仕方の変化 After まず仕様を考え、最小限度のテスト書き、その後実装。 必要があれば別のパターンのテストを書き、実装。徐々に育てていく。 小さくテストを書こう まずは仕 様と意図 を明確にし よう 実装するか
18. 実装の仕方の変化 Q: なぜAfterになった？ A: テスト・実装ともに改善できたから テストから先に書くことにより、仕様を考えたり、期待値を考えたり、検証内容を考えることに集中 できる。 テストから書き始めた場合、テストは実装に依存していない状態なので、怪しい匂いを感じた時点 で対処できる。 それは結果として設計や実装の改善に繋がった。 （テストを書くことで設計も行っている）
19. 実装の仕方の変化 課題の解決法の例 1. アサートファースト アサートから書くと以下のようにシンプルに分けて考えられるようになる。 1.1. 期待値を明確にすることを考える（というかせざるを得ない）。 1.2. どう検証すべきかを考える。 2. テストの独立性を保つ 例えばアサートを一つにする。すると自然と検証内容もシンプルになる。 3. 最初はシンプルな1パターンのみ考える。（複数パターンの検証が考えられる場合） こうすると、実装の際はシンプルな一つの仕様を満たすことだけを考えればよく、実装も最 初は最小限度となる。更に自然とテストもアサートが 1つになっていく。
20. テスト・実装に対する 価値観、行動の変化
21. テストコードに対する価値観の変化 Before ・「実装したコードが100%で意図した通りに正しく動くならば テストコードがいらないのでは？」 ・「実装コードと、そのテストがあればいいよね」 After 1. テスト→実装→テストのサイクルだと、実装はテストをグリーンにするために存在 2. テストは、実装内容についてだけでなく、仕様 (要件)を満たしているかの確認のために存在 3. 意図しないグリーンなテストは実装が間違ってしまっている可能性もある テストの地位が明らかに上がった
22. ちょっとしたコードの書き方の変化 Before 個人で新しい言語を勉強しているとき、こんな書き方できるかなみたいな確認をするとき、実装か ら始めていた。 After 上記のようなケースでも、まず検証するコード（当然落ちる）から書くようになった。 なぜAfterになったか どういうことをさせたい、どうなっていてほしいのか、どう使えると嬉しいのかをコード上で明確にし てからの方がやりやすいと感じるようになったため。
23. プログラミング以外の変化
24. 仕事の進め方の変化 Before すべてやりきるところまで一気に進めていた。失敗には最後になってから気づいていた。 After 全体のゴールは考えつつ、小さなゴールを定めて進めることが多くなった。 プロジェクトでも、小さく一つだけ実施してフィードバックを得て、徐々に育てるようになった。 なぜAfterになったか 大概のことは想定通り進まず、実際にやってみるまで不確定な要素が多い。 そういう場合では、フィードバックループは早い方がいいことが多いと考えるようになったため。
25. 仕事の進め方の変化 つまり考え方は応用がきく TDDの 「迅速にフィードバックを得て、その結果を活かすことを繰り返す」 という考え方は、プログラミング以外に対しても効果を発揮する。 （シンプルに考えるという部分も）
26. 仕事の進め方の変化 そもそもフィードバックは XPの5つの価値の1つであり、他の概念とも関連しているので、それぞ れにフィードバックがどう関わっているのかというのも興味深いトピックだと思う。 XP 「XPチームはできるだけ早く、できるだけ多くのフィードバックを生み出そうとする。 フィードバック のサイクルを数週間や数か月ではなく、 数分や数時間に短縮しようとする。フィードバック が 早く 手に入れば、 その分だけ早く適応できる。」 - エクストリームプログラミング (Kent Beck) -
27. 仕事の進め方の変化 CI 「CIの中心的な原則の一つは、インテグレーションを「早めに」、かつ「頻繁に」行うこと」 「迅速なフィードバックにより、いち早く軌道を修正して変化に適応するための時間がもたらされ る」 - 継続的インテグレーション入門 (Paul Duvall) -
28. 仕事の進め方の変化 CD 「フィーチャやバグフィックスがユーザーにとって役に立つかは、実際ユーザーの手に渡るまでは 推測に過ぎない。 (中略) したがってサイクルタイムを最小化し、効果的なフィードバックを構築できるようにすることがきわ めて重要。」 - 継続的デリバリー (Jez Humble, David Farley) -
29. 心にゆとりを持ち、自信に繋がる Before 自分のコードが、不具合を引き起こしていないか不安になり動作確認をたくさんしてしまってい た。 After 1. デプロイされるものは、テストされたものである前提が生まれる。 圧倒的安心感！ 2. 逆にテストがないと、どんなに正しいコードでも不安になる！
30. TDDの実践を経て（まとめ） • 設計・実装・テストに対する価値観が変わった • 仕事においての考え方にも影響をもたらした
31. 書籍の紹介 テスト駆動開発 Kent Beck(著), 和田 卓人(翻訳) 実践テスト駆動開発 - テストに導かれてオブジェクト指向ソフトウェアを育てる - Steve Freeman (著), Nat Pryce (著), 和智 右桂 (翻訳), 高木 正弘(翻訳)
32. Thank you for Listen!