tdd-hajime-no-ippo

Transcript

1. テスト駆動開発はじめの一歩 2024/01/16 家永英治
2. 自己紹介 いえぴょん/家永英治 私とテスト駆動開発と運命的な出会い 2002年ごろ学生時代に平鍋さんのXP記事でペアプロ帽子の写真をネットで目 撃。楽しそうだなと思い門を叩いて、2003年に永和に運良く入社 2005年ごろに、チーム角谷にラッキーにもジョイン。twadaさんがTDDを含 めてXPコーチ。その時にテスト駆動開発のファンに 角谷さん、twadaさんがチームから卒業後、数年はメンテナンス修正のメイ ン担当。途中慌てるシーズンもあったが、テストとともにプロダクトを育て ることの大事さを改めて実感 現在はペアプロコーチ、アジャイルコーチ。ペアプロやTDDを含めて アジャイルの楽しさ嬉しさを伝えていくことを私のミッションに https://www.agile-studio.jp/people/ienaga ペアプロコーチ アジャイルコーチ
3. テスト駆動開発とは？
4. テスト駆動開発は プログラミング ワークフロー （Kent Beck）
5. 実現し たいこ と ぼんやりしたのを 一度に変換するこ とは難しい！ 動作するプロダクト（顧客 に価値があり開発者にとっ てメンテナンスできる）
6. 仕様を まとめる 関数の インター フェース 設計する 実装＆ テスト＆リ ファクタす る
7. 仕様を まとめる 関数の インター フェース 設計する 実装＆ テスト＆リ ファクタす る 何ができれば完成と言えるか 明瞭にするが難しい 一度に全てを見通して 計画通りつくるは難しい わかりやすい インタフェースと 実装の分離が難しい リファクタ余裕がなくなって 技術的負債がたまり、 ますますデバック地獄に 実態はエラーの連続で デバック地獄！ 当初の設計では まずいにあとで気づく
8. そこで、TDDは問題を 小さく分割して ベイビーステップで 確実に１つ１つ完成させる
9. TDDは、小さくても 実際に手を動かして 得た学びを大事にする
10. 動作するプロダクト（顧客 に価値があり開発者にとっ てメンテナンスできる） 実現 した いこ と
11. 実現 した いこ と 動作するプロダクト（顧客 に価値があり開発者にとっ てメンテナンスできる） テストリスト Red Green Refactor
12. https://bliki-ja.github.io/TestDrivenDevelopment
13. https://bliki-ja.github.io/TestDrivenDevelopment 1.テストケースの リストを書き出す テストリストを使って実現したいことを明確に するため どの順序でつくると良さそうかの初期計画をた てるため
14. https://bliki-ja.github.io/TestDrivenDevelopment 2.ひとつのテストを 選択する はじめの一歩目となる小さいテストを選んで実際に 手を動かし学びを得るスタートを切るため
15. https://bliki-ja.github.io/TestDrivenDevelopment 3.テストを書く （レッド） 何ができたらOKと言えるかをマシンで判定 できるほどに明確にするため 関数のインタフェース設計をするため
16. 4.テストをパスさせる （グリーン） 難しいなら、ベタ書きの仮実装でも構わない https://bliki-ja.github.io/TestDrivenDevelopment
17. 5.リファクタ 学びを生かして後から理解しやすく修正しやすくするため ベタ書きを一般化して本物に近づけるため https://bliki-ja.github.io/TestDrivenDevelopment
18. https://bliki-ja.github.io/TestDrivenDevelopment ひとつのテストを選択し 完成させる(繰り返し)
19. https://bliki-ja.github.io/TestDrivenDevelopment 6.学んだことがあれば リストを更新する 実際に手を動かすことで得た学びを計画に反映させるため
20. 目的地 本命と思ってた 当初計画ルート 代案の 急がば回れルート に変更 後から 進めないと わかる
21. 既存バグを発見し 先に対応が必要と わかった テストケースX1 が抜けていること がわかった 外部ライブラリー エラーXに 出会った 実際に手を動かすことで当初の計画通り進まない と後から発見することもある （慌てないで。学んだことを生かして計画を更新し 続けるは、アジャイルの基本の型） 設計方針Aでは 実現できないこと がわかった 現状のままだと 機能修正が難しく 先にリファクタが必要とわかった 仕様を 誤解していたと わかった
22. 15分、30分堂々めぐりして 先に進めないなら 仲間に相談しよう！
23. テスト駆動開発を学ぶには？
24. • 動画や実演を見て疑似体験する （事前視聴、今日） • 実際に手を動かして学ぶ（今日） ◦ 練習お題のリンク ▪ https://archive-devtesting-jp.github.io/tddbc/index_archive.html ▪ 例えば、FizzBuzz、 スタック、 ボウリングゲーム、整数の区間、ライフゲーム ◦ 同僚とならペアやモブなどを組んで相互に学び合う ◦ 自主練習なら生成AIとペアプロしながらTDDについて学んでみる ◦ やったことをふりかえり、自分でわからなかったこと整理し、生成AIや同僚に質問してみる • 実際の案件でテスト自動化=>テストファースト=>TDDに取り組む ◦ 後でまとめてテストでデバック地獄ではなくて、早めにこまめにテストに取り組む ◦ テストファーストを試してみる ◦ テスト駆動開発を試してみる ◦ やったことをふりかえり、自分でわからなかったこと整理し、生成AIや同僚に質問してみる • 書籍で落ち着いて学んで、実務に応用する ◦ 「リファクタリング （マーチン・ファウラー）」 チュートリアルを実際に手を動かして学ぶはおすすめ ◦ 「Clean Code　アジャイルソフトウェア達人の技（ロバート・C. マーチン）」 ◦ 「テスト駆動開発 （ケント・ベック）」 • 研修やTDDに関連する社内外部コミュニティで学んで、実務に応用する ◦ TDDBC、Coderetreat、TDDワイワイ会、テスト駆動飲み会 etc… ベイビーステップでテスト駆動開発を学んで実務で使うには？
25. 動画で疑似体験で学ぶ https://www.youtube.com/watch?v=Q-FJ3XmFlT8
26. 見て感じて欲しいポイントをいくつか テストリストに分解することでゴールや段取りが明瞭すっきり 頻繁にテスト実行し確認することの安心感 ベイビーステップで進めること、つまづいた時にリカバーしやすい テストのクラス名やメソッド名がドキュメントとして機能しなにができるか明確 etc… （他にも、たくさん見つけてね。）
27. https://agilejourney.uzabase.com/entry/2023/11/30/103000 動画見たら合わせて読むがおすすめ
28. 手を動かして学ぶ https://www.agile-studio.jp/post/twop-refactor-tdd-ren
29. 書籍から学ぶ
30. 頻繁にテスト実行しながら 作っているデモ （15分程度）
31. 改めて、テスト自動化や テスト駆動開発に取り組む 理由はなんだろうか？
32. https://www.agile-studio.jp/post/twop-test-goals
33. アジャイルな開発者として 私は、〇〇したい。 なぜなら、デバッグ地獄から抜け出し、 コードや設計に対して根拠ある自信をも ち、顧客に嬉しさを届けたいからだ TDD? CI/CD? ペアモブ？ 小さい単位のプ ルリク？ 関数型パラダイ ム？ リファイメント？ AIとの共同 ワーク? テスト自 動化？ DDD？ ATDD/ BDD？
34. 私としては、 テスト駆動開発を気に入っているので、 ファンになってくれる人が 増えると嬉しい😀
35. 補足１：リファクタリング
36. リファクタリング（名詞） 外部から見たときの振る舞いを保ちつつ、 理解や修正が簡単になるように、 ソフトウェアの内部構造を変化させること
37. なぜリファクタリングする？ • ソフトウェアの設計改善のため • ソフトウェアを理解しやすくするため • 機能追加を容易にするため • バグ発見を助けるため • プログラミングを速めるため
38. 読みやすく、修正しやすい状態 を保ち、開発ペースを 維持や速める （デザインスタミナ仮説）
39. ６章のリファクタリング始めの一歩を覚えよう 関数の抽出 変数名の変更 関数のインライン化 パラメータオブジェクトの導入 変数の抽出 関数群のクラスへの集約 変数のインライン化 関数群の変換への集約 関数宣言の変更 フェーズの分離 変数のカプセル化
40. 今なら生成AIを使って、スマホで学べる時代 リファクタリングの関数の抽出 の例を知りたいです。
41. テスト駆動開発同様に、 実際に手を動かして学ぼう （１章はチュートリアルで、 手を動かして学ぶ教材になってます）