みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf

TechRAMEN 2024 Conference の発表資料です
https://fortee.jp/techramen-24-conf/proposal/15047b38-b193-4320-8078-f6487db0d63e

Transcript

1. みんなでワイワイ 
 「テスト駆動開発」の話をやる会 TechRAMEN 2024 Conference Hideki Kinjyo GitHub: o0h / X: @o0h_
2. グループワーク用に テスト/TDDプロフィールカードを作ろう!! プログラミング経験(実務)年数 TDDレベル ★: 初級者 ・・未経験、これから ★★: 経験者・・やったことがある、たまに使う ★★★: ベテラン・・日常的に使う テスト(単体テスト、自動化テスト)レベル ★: 初級者 ・・未経験、これから ★★: 経験者・・やったことがある、たまに使う ★★★: ベテラン・・好きぃ〜〜 事前準備 卓上の情報カードとペンを 使って作成後、同じグルー プの人から見えるように置 いてください！ 例 =>
3. みんなでワイワイ 
 「テスト駆動開発」の話をやる会 TechRAMEN 2024 Conference Hideki Kinjyo GitHub: o0h / X: @o0h_
4. 自己紹介 • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏 : @o0h_ • アイコンは美味しい鮭親子丼の写真です • 普段は東京のIoT会社でバックエンドやってます
5. 自己紹介 • 普段はPHP系のコミュニティに出入りしています • 好きなFWはCakePHP • 今年は"毎月発生していた"PHP系カンファレンスに参加しました💪 • 北海道、大阪、東京、神奈川、香川、福岡 • 機会があると登壇したりも • (直近だと)EM、モニタリング、テスト・設計、デバッガ、データ構造…なんて 
 その時々で浮かんだネタで発表しています
6. 今日やること 発表者の話を聴くのではなく 
 みんなでワイワイ「テスト駆動開発」の話をやる
7. なんで？ <経験も所属も抱えている課題も違う人たち> 
 せっかく同じイベントに色々な人が集まっている && <コミュニティの素敵なところ!!> 
 「初めまして」同士でも同じ話題で盛り上がれる
8. 閑話休題: ちょっとアンケート 北海道内から or 道外から来た人〜？
9. 閑話休題: ちょっとアンケート プログラミング歴〜？
10. 閑話休題: ちょっとアンケート お仕事〜？ 
 アプリケーションエンジニア 
 or それ以外ITエンジニア 
 or それ以外社会人 
 or 学生
11. 閑話休題: ちょっとアンケート TDD〜？ 
 未経験 
 or やったことはある 
 or たまにやっている 
 or 日常的にやっている
12. なんで？ <経験も所属も抱えている課題も違う人たち> 
 せっかく同じイベントに色々な人が集まっている && <コミュニティの素敵なところ!!> 
 「初めまして」同士でも同じ話題で盛り上がれる
13. なんで？ <だったら> ワイワイ話したら面白そうじゃない？？
14. 今日のテーマ テスト駆動開発:TDDで◯◯なりたい をワイワイ話しましょう
15. 近くの2,3人で組んで、 
 「自己紹介タイム」をやってみてください ※折角なので、ﾊｼﾞﾒﾏｼﾃの人がいる所に 
 移動してみるのも良いかも？ 今日の 
 オープニング後に やったやつと 
 同じ！
16. やること(流れ) 1. 出だし ★今ココ 2. <おさらい> 教科書通りのTDDを駆け足で 3. <つなぎ> 書籍や発表資料から「TDDの効果」について共有 4. <メイン> 「TDDで◯◯なりたい」について議論 (小グループで) 5. <クロージング> 話したことの共有
17. 2. 教科書通りのTDDを駆け足で
18. このセクションのねらい • 基本的なTDDのやり方を体感する • 「へぇ〜」ってなったり • 思い出したりする • 議論にするにあたっての「TDDってああいうのだよね」の認識を揃える
19. TDDとは？(怪しい説明)
20. TDDとは？ TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” - レバテックラボ（レバテックLAB） https://levtech.jp/media/article/interview/detail_477/
21. テスト駆動開発とは？ 「一般的」な開発 機能を開発して、 
 欠陥がないことを 
 テストを実施によって 
 確認する テストファースト 最初にテストを書いて 
 必要な項目が列挙し、 
 合致するよう 
 機能を開発する テスト駆動開発 やりたい事を 
 小さいテストで表現し、 
 合致するよう機能の開発、 
 機能・テストが揃った状態 で双方のコードを整える、 
 を反復的に進める
22. 例えばFizzBuzz • 1から100までの数字について、次のルールに従って値を返す • 数字が3で割り切れるときは「Fizz」 • 数字が5で割り切れるときは「Buzz」 • 数字が3と5の両方で割り切れるときは「FizzBuzz」 • それ以外のときはその数字をそのまま出力
23. 例えばFizzBuzz • [ ] 1〜100の数字を受けとり、何かを出す • [ ] 簡単そうなのは「数字をそのまま出力する」なので、そこを扱う • [ ] 「3で割り切れる時はFizz」を扱う • [ ] 「5で割り切れる時はBuzz」を扱う • [ ] 「3でも5でも割り切れる時はFizzBuzz」を扱う
24. 例えばFizzBuzz 1〜100の数字を受けとり、何かを出す ※ ニセPHPです。実際のPHPとはルールが異なります。
25. 例えばFizzBuzz fizzBuzz(); 1〜100の数字を受けとり、何かを出す => 「FizzBuzzする」関数を呼べるようにする ※ ニセPHPです。実際のPHPとはルールが異なります。
26. 例えばFizzBuzz fizzBuzz(); 1〜100の数字を受けとり、何かを出す => 「FizzBuzzする」関数を呼べるようにする 実行不可能なのでエラー ※ ニセPHPです。実際のPHPとはルールが異なります。
27. 例えばFizzBuzz function fizzBuzz(){ } fizzBuzz(); 1〜100の数字を受けとり、何かを出す => 「FizzBuzzする」関数を呼べるようにする 実行可能なfizzBuzzを定義 ※ ニセPHPです。実際のPHPとはルールが異なります。
28. 例えばFizzBuzz function fizzBuzz(){ } fizzBuzz(); 1〜100の数字を受けとり、何かを出す => 「FizzBuzzする」関数を呼べるようにする 実行可能になったので 「グリーン」 ※ ニセPHPです。実際のPHPとはルールが異なります。
29. 例えばFizzBuzz function fizzBuzz(){ } fizzBuzz(); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す ※ ニセPHPです。実際のPHPとはルールが異なります。
30. 例えばFizzBuzz function fizzBuzz(){ } fizzBuzz($i); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す ※ ニセPHPです。実際のPHPとはルールが異なります。
31. 例えばFizzBuzz function fizzBuzz(){ } fizzBuzz($i); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す 引数不一致で 
 エラー ※ ニセPHPです。実際のPHPとはルールが異なります。
32. 例えばFizzBuzz function fizzBuzz($i){ } fizzBuzz($i); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す 引数を使えるように ※ ニセPHPです。実際のPHPとはルールが異なります。
33. 例えばFizzBuzz function fizzBuzz($i){ } fizzBuzz($i); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す 呼び出せた！ ※ ニセPHPです。実際のPHPとはルールが異なります。
34. 例えばFizzBuzz function fizzBuzz($i){ } $actual = fizzBuzz(true); 
 assert(any($actual)); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す
35. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } $actual = fizzBuzz(true); 
 assert(any($actual)); 1〜100の数字を受けとり、何かを出す => 何かを受け取り何かを出す テストの声に従い 
 中身の実装
36. 例えばFizzBuzz / 更新されたTodoList • [x] 1〜100の数字を受けとり、何かを出す • 呼び出し可能な関数「fizzBuzz()」を用意する • 値を受け取れるようにする • 何かを出すようにする • [ ] 簡単そうなのは「数字をそのまま出力する」なので、そこを扱う • [ ] 「3で割り切れる時はFizz」を扱う • [ ] 「5で割り切れる時はBuzz」を扱う • [ ] 「3でも5でも割り切れる時はFizzBuzz」を扱う
37. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } fizzBuzz(1); 1〜100の数字を受けとり、そのまま出す => 数字を受け取る 数字を受け取っている様子を 
 テストで再現
38. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } fizzBuzz(1); 1〜100の数字を受けとり、そのまま出す => 数字を受け取る これは今のままでも通ってしまう！
39. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } fizzBuzz(1); 1〜100の数字を受けとり、そのまま出す => 数字を受け取る 「失敗する」ことを 
 確認するまでは 
 次に進まないようにする
40. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } fizzBuzz(1); expectError( 
 TypeError, fizzBuzz('͋͋͋') 
 ); 1〜100の数字を受けとり、そのまま出す => 数字"のみ”を受け取る 「数字」と「それ以外」の 
 三角測量
41. 例えばFizzBuzz function fizzBuzz(int $i) { 
 return '͋͋͋'; 
 } fizzBuzz(1); expectError( 
 TypeError, fizzBuzz('͋͋͋') 
 ); 1〜100の数字を受けとり、そのまま出す => 数字"のみ”を受け取る 引数の型を制限することで実現
42. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } 1〜100の数字を受けとり、そのまま出す => 受け取った数字をそのまま出す もう少し問題を分解(単純に)できる
43. 例えばFizzBuzz function fizzBuzz($i){ 
 return '͋͋͋'; 
 } 1〜100の数字を受けとり、そのまま出す => 入力が1の時に1を返す assert(1 == fizzBuzz(1));
44. 例えばFizzBuzz function fizzBuzz($i){ 
 return 1; 
 } 1〜100の数字を受けとり、そのまま出す => 入力が1の時に1を返す assert(1 == fizzBuzz(1));
45. 例えばFizzBuzz function fizzBuzz($i){ 
 return 1; 
 } 1〜100の数字を受けとり、そのまま出す => 入力が7の時に7を返す assert(1 == fizzBuzz(1)); assert(7 == fizzBuzz(7));
46. 例えばFizzBuzz function fizzBuzz($i){ if ($i == 7) { return 7; } 
 return 1; 
 } 1〜100の数字を受けとり、そのまま出す => 入力が7の時に7を返す assert(1 == fizzBuzz(1)); assert(7 == fizzBuzz(7));
47. 例えばFizzBuzz function fizzBuzz($i){ if ($i == 2) { return 2; } 
 if ($i == 7) { 
 // লུ 1〜100の数字を受けとり、そのまま出す => 入力が2の時に2を返す assert(1 == fizzBuzz(1)); assert(7 == fizzBuzz(7)); assert(2 == fizzBuzz(2));
48. 例えばFizzBuzz // লུ 
 if ($i == 7) { 
 return 7; 
 } -- return 1; ++ return $i; 
 } 1〜100の数字を受けとり、そのまま出す => 受け取った数字をそのまま出す assert(1 == fizzBuzz(1)); assert(7 == fizzBuzz(7)); assert(3 == fizzBuzz(3)); assert(2 == fizzBuzz(2)); assert(4 == fizzBuzz(4)); assert(5 == fizzBuzz(5));
49. 例えばFizzBuzz function fizzBuzz($i){ return $i; } 1〜100の数字を受けとり、そのまま出す => 受け取った数字をそのまま出す assert(1 == fizzBuzz(1)); assert(7 == fizzBuzz(7)); assert(3 == fizzBuzz(3)); assert(2 == fizzBuzz(2)); assert(4 == fizzBuzz(4)); assert(5 == fizzBuzz(5)); コードが散らかってきたのが 
 気になったタイミングでリファクタ
50. 例えばFizzBuzz / 更新されたTodoList • [x] 1〜100の数字を受けとり、何かを出す • 呼び出し可能な関数「fizzBuzz()」を用意する • 値を受け取れるようにする • 何かを出すようにする • [x] 簡単そうなのは「数字をそのまま出力する」なので、そこを扱う • 入力が1の時に1を返す • 入力が7の時に7を返す • 入力が2の時に2を返す • 受け取った数字をそのまま出す • [ ] 「3で割り切れる時はFizz」を扱う • [ ] 「5で割り切れる時はBuzz」を扱う • [ ] 「3でも5でも割り切れる時はFizzBuzz」を扱う
51. 教科書通りのTDDの進め方 • どうなっていればいいか・何が足りていないか、のToDoリストを作る • ToDoリストの上から(やりやすいところから)テストで表現する • テストの失敗(Red)→成功(Green)→整理(Refactoring)のサイクル • テストコードもプロダクトコードも整理し続ける • 「ベイビーステップ」で進める • 複数の問題を同時に扱わない • タスクを分解して考える
52. 3. 書籍や発表資料から「TDDの効果」について共有
53. このセクションのねらい • やり方はおさらいしたけど、「それでどうなる」の例を示す • なんで世間はこんなにもTDDに称賛の声を送るのか・・？の片鱗 • 議論するにあたって、みなさんの中の好奇心を刺激する • TDDに対する「こんなことに興味があるかも」という風呂敷を広げる
54. TDDでコードを書くのは「ゴールから逆算している」わけではない たまに「和田さんは、コードを書く前から機能の完成形をちゃんと見通せている から、先にテストを書けるんですよね」と言われることがあるんですが、そうじゃ ないです。むしろその逆で、先々が見通せていないからこそテストを書くんです。 ——完成形から逆算してテストを書いているわけじゃないんですか？ 和田：はい。TDDを実践しながらコードを書く感覚をたとえるなら、不確実性にま みれたソフトウェア開発に少しずつ確実性を持たせていく、一種の陣取り合戦みた いなものです。 色々な人が言っていること t-wada氏に聞く、テストを書き始めるための「はじめの一歩」 - レバテックラボ（レバテックLAB） 
 https://levtech.jp/media/article/interview/detail_480/
55. 色々な人が言っていること TODOリストの整理を通じて実行すべきテストを考える #tddbc / TDDBC 2020 Online LT - Speaker Deck 
 https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt 最初に考えた事でも可変、常に調整し続ける
56. TDDは工学的にどう「良い」と言えそうか？ 個々の論文が、TDDの効果をどう評価しているか、以下の10項目に分類していま す。 欠陥の密度や量 (amount and density of defects) コードカバレッジ (code coverage) コードの複雑度 (code complexity) 結合度 (coupling) 凝集度 (cohesion) サイズ (size) 工数 (effort) 外部品質 (external quality) 生産性 (productivity) メンテナンス性 (maintainability) 19の研究を調査した結果、欠陥の減少とメンテナンス性の向上がTDDの効果として 期待できると言えます。TDDでは全体コードサイズが増えますが、コードカバレッ ジはよくなります。 色々な人が言っていること TDDの効果の研究をまとめた研究 - やっとむでぽん 
 https://yattom.hatenablog.com/entry/20131103/p1
57. コンディションや「不安」で歩幅をコントロールする 直接正解と思われるコードを書いてしまうこともある．これを，“明白実装” （Obvious Implementation）といいます．自分に自信がある場合，テストを作って すぐに明白実装を する，という赤緑赤緑の２拍子で進んでもいいです．しかし、 自信がない場面では，フェイクして，ト ライアンギュレーションして，そしてリ ファクタリングして正解と思われる実装に持っていった方がよ い．この切り替え は，ペアの自信と力量，それにコンディションによります．少し寝不足の時など は， 小刻みにフェイクした方が，リズムが取れて良いときがありますよ． 色々な人が言っていること オブラブ - テスティング 
 https://objectclub.jp/technicaldoc/testing/
58. 色々な人が言っていること 楽しさ、支配している感じ 自分は宇宙の支配者であり、すべてのコンピューターが自分のパワーの前にひれ 伏すことを知り、ニヤリとしながら画面から立ち去ったときだろうか？ TDDのループを回すたびに得られるのは、そうした感情が小さく反響したものだ。 期待どおりにテストが失敗すると、ニヤリとしながらうなずいてしまう。テストが パスするようなコードを書くたびに、かつては自分は宇宙の支配者であり、今でも そのパワーが残っていたことを思い出す。 Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ; 角 征典. 
 Clean Craftsmanship　規律、基準、倫理 (アスキードワンゴ) (p.59). 株式会社ＫＡＤＯＫＡＷＡ. Kindle 版.
59. よく言われること • 設計が良くなる • テストを書くのが楽しくなる • リファクタが怖くなくなる • コードを書く時間は増えるが、手が止まる時間が減る
60. 4. 「TDDで◯◯なりたい」で話そう〜
61. テーマ: TDDで◯◯なりたい つまりどういうこと？というと・・・(例・射程) • TDDを使いこなして、どんなプログラマになりたいか • プログラマ的な課題に、TDDはどう対応しそうか • こんな風に、TDDを使いたい。使い始めてみたい
62. やること・ゴール • 3〜4人程度の小グループでワイワイ話してください！ • 最終的に、1つの「◯◯なりたい」を決めて、 
 グループの代表者に発表してもらいます！
63. 議論する時のコツ① • バックボーンや知識の異なる人同士の意見交換を楽しんでください！ • 誰に対しても 
 「話は遮らないで聞く」「ずっと喋りすぎない」を意識しましょう • 話すのが苦手な人、初対面で疲れてる人も 
 マイペースで参加すればOK〜っていう雰囲気、作っていきましょう！ • 余裕がある人は、リアクションを大きめにしてくれると温まります！ • 相槌、笑い(声・笑顔)、共感のﾜｶﾙ-ﾅﾙﾎﾄﾞ-の声
64. 議論する時のコツ② 「正解を知る」ではなく「咀嚼する」がこの場でやりたいことです！ 
 => 色々な立場からできる貢献があります • 未経験者、初級者 • 「素朴な疑問」を投げかける役割を担ってください 
 「ココまではわかった」「ココがピンときてない」など • 場に対して「丁寧な言語化にチャレンジする」のに繋がります • 経験者 • 自身の経験したこと・知っていることを積極的に共有する役割を担ってください • ベテラン • 「パターン化」「抽象化、本質に迫る視点を提供する」役割を担ってください
65. 進め方の例・目安 • 最初のn分で「TDDについての疑問」「期待」を 
 ざっくばらんに話してみる • どう始めるの？いつ使う？使ってみようと思ったきっかけは？ • TDDってこういうことも上手く出来るようになる？ • プログラミングやっていてこういう所が難しい〜 • おおよその「◯◯なりたい」を絞って、議論の方向性を確認する • 最後のn分で「まとめ」に入る
66. 発表例 〜xx:xxマデ • TDDで◯◯なりたい ← ◯◯に何を入れたのか教えて下さい • 次のようなポイントを教えて下さい(例) • どうしてその◯◯を選んだのか、何を期待しているのか。何が解決されるか • そのために実践したいことは？(コツ、心がけたいこと) • 話したけど解消されていないこと、詳しい人に聞いてみたいこと • 厚めな紙・ペンを用意しているので、まとめてみてください • あとでブログにしたいので物証を残そう！！！！！！！！！
67. 5. 話したことの共有
68. 6. まとめ(閉会の挨拶)
69. 楽しんでもらえれば幸い中の大幸いです！ • TDD、とても奥深くて魅力的な技法・思考法です。 
 やっていきたい！！！！！！！！ • こういう場で「ざっくばらんに誰とでも喋ってみる」のは、 
 技術コミュニティが楽しくなる1つの魅力かな〜と思います • 「すごい・有名な人」が野生の存在として歩いてるのも面白いところ。 
 でも話しかけるのが怖い・・なんて声かければ・・ 
 => 今ここで出た「コレどうしてるんだろう？」をぶつけるチャンス！
70. おしまい！ ご参加いただき ありがとうございました!!