『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya

Slide 1

Slide 1 text

『テスト書いた方が   開発が早いじゃん』を解き明かす PHPカンファレンス名古屋2025 Hideki Kinjyo GitHub: o0h / X: @o0h_ [公開用]

Slide 2

Slide 2 text

イントロこんにちは！！   いつも楽しくテストを書いてますか？

Slide 3

Slide 3 text

イントロ「でも、テストを書く時間が無いんです」

Slide 4

Slide 4 text

イントロ「でも、テストを書く時間が無いんです」その分の工数が増えるじゃん

Slide 5

Slide 5 text

イントロ「あなたが言っているのは、中長期的な話ですよね」テスト書く方が効率良いよ

Slide 6

Slide 6 text

イントロ [ग़య]   ᴷ Meszaros, Gerard.   ʰxUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) Kindle dition. ʱP20

Slide 7

Slide 7 text

イントロ「そうじゃないんすよ」「短いサイクルで見ても、行けるはずなんすよ」ほら、   イニシャルコストじゃん

Slide 8

Slide 8 text

イントロ「テストを書いていないから時間が無いんでしょ」書いた方が   効率が上がる・楽になるよ

Slide 9

Slide 9 text

イントロ「テストを書いていないから時間が無いんでしょ」書いた方が   効率が上がる・楽になるよ ʁ

Slide 10

Slide 10 text

なぜなのか

Slide 11

Slide 11 text

イントロテストを書く時間がない人「テスト書くような時間が無いです」テストを書いた方が開発が早い人「テスト書いた方が開発が早いじゃん」こういうこと？

Slide 12

Slide 12 text

テストを書く時間がない人「テスト書くような時間が無いです」テストを書いた方が開発が早い人「テスト書いた方が(開発が)早いじゃん」イントロきっと何かの   ギャップがあるぞ

Slide 13

Slide 13 text

テストを書く時間がない人「テスト書くような時間が無いです」テストを書いた方が開発が早い人「テスト書いた方が(開発が)早いじゃん」イントロきっと何かの   ギャップがあるぞこれを解き明かす！

Slide 14

Slide 14 text

本日のテーマ中長期的な目線ではなく、短期的な目線でも「早い」を助けるテストの考え方/使い方を知って、明日からの開発を助ける武器を増やそうトーク

Slide 15

Slide 15 text

本日のテーマ 🙅 良いテストを書きましょう   🙅 テストでプロダクトの価値を高めましょう 🙅 組織でテストを書ける土壌・文化を築きましょう ⇓ 「保守」「持続可能性」の話ではなくて・・

Slide 16

Slide 16 text

本日のテーマ 🙆「テストを書く」ことで何が助けられるのか 🙆「でもウチはテスト書いてなくて」で諦めない ⇓ 個々人の、目の前の「早さ」を獲得するヒント

Slide 17

Slide 17 text

自己紹介 • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏 : @o0h_ • 好きなFWはCakePHP • アイコンは美味しい鮭親子丼の写真です • 最近はPodcastをやっています • ハッシュタグ: #readlinefm • これで3年連続・4度目の名古屋です

Slide 18

Slide 18 text

おしながき 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 19

Slide 19 text

注意 • この発表中では、開発者自身が作成する、実行可能なコードとして記述されるソフトウェアテストのことを簡易的に「テスト」と呼びます • 手動や目検で「合否」を判定するテストは含みませんが、必ずしも起動や実行前のセットアップが完全に自動化されているものには限定しません

Slide 20

Slide 20 text

1. プログラミング難しいね   → 現実(物理)と比べて無秩序な世界！ 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 21

Slide 21 text

(楽をしたくなるほどに) プログラミングは難しい作業

Slide 22

Slide 22 text

プログラミング難しい三選 ① プログラミングは複雑 ② プログラミングは緩慢 ③ プログラミングは曖昧

Slide 23

Slide 23 text

難しさ① <複雑さ> 考えることが多くて、とっても複雑

Slide 24

Slide 24 text

① 複雑さ: 考えることが多くて、とっても複雑プログラミングは、   複数の計算・処理を組み合わせる活動。様々なレイヤーを行ったり来たりしながら、   同時多発的に作業を行う。忙しい！

Slide 25

Slide 25 text

① 複雑さ: 考えることが多くて、とっても複雑

Slide 26

Slide 26 text

① 複雑さ: 考えることが多くて、とっても複雑「有効なユーザー名」のルールを確認しなきゃ判定は正規表現？バリデーションのライブラリって入ってるんだっけ？このルールを使うのはここだけ？失敗したらfalse? 例外投げる？事前にチェックされてるのは？nullも来る？string だけ？メソッドを切るのが良いのかな、インラインでいいのかな引数名はどうしよう違反内容はどこまで記述する？メッセージはUIにそのまま出される？別で解釈される？文言、ですます長だっけ？

Slide 27

Slide 27 text

Slide 28

Slide 28 text

難しさ② <緩慢さ>   制約が「ソフト」で、   逸脱や違反に対して鈍感

Slide 29

Slide 29 text

② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感プログラミングは、   論理的な世界で成り立つ活動。物理の世界にあるものと違って、   簡単に「逸脱」を起こしやすい。

Slide 30

Slide 30 text

② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 ★物理の世界なら？みんなに   ケーキを切り分けよう！多くて8人くらいかな

Slide 31

Slide 31 text

② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 ★物理制約から開放された自由な世界─── $me->cut($cake, -10000) みんなに   ケーキを切り分けよう！

Slide 32

Slide 32 text

② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 $me->cut($cake, -10000) みんなに   ケーキを切り分けよう！ビジネス現実なら「意識する前から存在していた法則」が   物理世界に留まるようにガイドするが、   制約はプログラマが恣意的に与える必要がある。   ⇓ 「自然」がなく、常に思考に負荷が掛かる

Slide 33

Slide 33 text

難しさ③ <曖昧さ> 実現したいことに対して、   実装方法や完成度が曖昧

Slide 34

Slide 34 text

③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧プログラミングは、   要求や目的に沿ってコードへ翻訳する活動。「問い」があっても   必ずしも「解法」の形を規定せず、   正解や完成の度合いも明確になりにくい。

Slide 35

Slide 35 text

③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」

Slide 36

Slide 36 text

③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」まずは牛乳や卵が買える場所に行かないとお金が要るな、   財布を持っていこう (現実では)問題が出された時点で、凡その「解き方」が決まる。

Slide 37

Slide 37 text

Slide 38

Slide 38 text

③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」牛乳は   ハードコーディングで良い？卵はキャッシュから使い回せる？だめ？ (プログラミングにおいては)問題が明確になりにくく、   解法は更に多くのバリデーションを発生させる買い物に行くのはログインが必要？匿名で良い？ビジネス「現実」から「論理」に翻訳するということは、   本質的に「形を変えて表現する」作業となる。   出題の意図と回答が、"==="で結びつかない世界。   ⇓   ゴールを「固定」しないと完成に到達しない

Slide 39

Slide 39 text

(楽をしたくなるほどに) プログラミングは難しい作業

Slide 40

Slide 40 text

(楽をしたくなるほどに) プログラミングは難しい作業 ⇓ 気づかない内に   め〜〜〜っちゃ負荷が掛かっていそう！

Slide 41

Slide 41 text

プログラミングの難しさに立ち向かう＼朗報／テストなるものが、   これらの困難を緩和する助けとなってくれるはず

Slide 42

Slide 42 text

1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 43

Slide 43 text

1. プログラミング難しいね 2. テストって何？友達になったら役立つの？   →ちょっとした秩序として考えてみる 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 44

Slide 44 text

そもそもテストってなんだ？ (色々な定義や観点があるが)   めっちゃ単純な言い方をすれば、   動かしてみて→答え合わせする一式のセット

Slide 45

Slide 45 text

そもそもテストってなんだ？ • `add(1, 100)` したら `(int)101` が返ってくるとか • ログイン状態で`/user/mypage` を開くと自分の名前が表示されるとか • 退会処理バッチを回したらユーザーの投稿が削除されるとかなんでも良いです！

Slide 46

Slide 46 text

テストを使って困難に立ち向かう ① 複雑さに立ち向かうテスト ② 緩慢さに立ち向かうテスト ③ 曖昧さに立ち向かうテスト

Slide 47

Slide 47 text

攻略①   複雑さに立ち向かうテスト

Slide 48

Slide 48 text

複雑さに立ち向かうテストなにが問題だったか:   1つの問題(仕様)を解くために、多様・雑多なステップが必要なことが「複雑さ」の問題だったどうして難しいのか:   複雑な問題に対する王道的なアプローチは「分割統治」。細かく分解して、個別的に対処するべき。   ただし、プロダクトコードでは無駄なステップを増やしたり過度な分解を適用することは難しい・・・

Slide 49

Slide 49 text

複雑さに立ち向かうテストテストが何を解決するのか:   プロダクトコードと違い、テスト(コード)は「冗長」を受け入れて「解剖」「複眼・比較」的な態度を歓迎する。よって、プロダクトコードと違って「問題を分解し、少しずつ確かめる」ための武器となるどう使うか:   分解した、小さな「問題」「期待(正解)」をたくさん書いていく

Slide 50

Slide 50 text

複雑さをテストで易しくする例複数の要素からなる配列を受け取る   コレクションクラス `avg()`メソッドで、全要素の平均を返す平均ってことは、   まずは全部を足して   要素数で割ればOK？要素が0個の場合も   考えないと int/floatだけとも限らないよな PHP_INT_MAX超えるかもしれない nullはどう扱おうかな

Slide 51

Slide 51 text

複雑さをテストで易しくする例平均ってことは、   まずは全部を足して   要素数で割ればOK？

Slide 52

Slide 52 text

複雑さをテストで易しくする例要素が0個の場合も   考えないと

Slide 53

Slide 53 text

複雑さをテストで易しくする例 int/floatだけとも   限らないよな

Slide 54

Slide 54 text

攻略②   緩慢さに立ち向かうテスト

Slide 55

Slide 55 text

緩慢さに立ち向かうなにが問題だったか:   「そんな使い方しないでよ〜・・・」といった常識では考えられない出来事でも、明示されない限りは起き得てしまう。   「決められていない事」に対し、ソフトウェアはフィードバックを出さないのが問題だったどうして難しいのか:   人間はどうしても「うっかり」を起こすし、「完全な視野」を持たない。思考に限界がある。もし制約とフィードバックがないのであれば、誤りに気づくことはかなり難しい

Slide 56

Slide 56 text

緩慢さに立ち向かうテストが何を解決するのか:   テストを書いて「合格・不合格」を明確に判定させることで、強い「制約」として利用できる。そうした制約を、1つずつ積み重ねていくことで、うっかり漏らしの対抗策とする。どう使うか:   「これは違反である」という使い方を再現したテストを作り、プロダクトコードが「拒絶」することを確かめておく

Slide 57

Slide 57 text

緩慢さをテストで取り締まる例求人案件の登録で、   提示年収を管理する機能年収って言ったら   300ドングリ以上だよね最近はドングリの代わりに   ハマグリを渡す会社も多いみたいだし、   対応して対応しておこう

Slide 58

Slide 58 text

緩慢さをテストで取り締まる例求人案件の登録で、   提示年収を管理する機能年収って言ったら   渡そうとしたら駄目だぞ明らかに   会社の資本力と見合っていない   ドングリやハマグリを受け付けるべきでないハマグリを使うなら   予め「ハマグリ輸送手段」が   設定されているべきだ

Slide 59

Slide 59 text

攻略③   曖昧さに立ち向かうテスト

Slide 60

Slide 60 text

曖昧さに立ち向かうなにが問題だったか:   仕様や要求は自然言語で、人間が読みやすいように書かれる。他方でプログラミング的な挙動については必ずしも厳密に示されない。翻訳的な作業が発生するのが問題だったどうして難しいのか:   プロダクトコード(= 変更され続けるもの)だけが   「正解を知っている」になると、答え合わせの方法がなくなる

Slide 61

Slide 61 text

曖昧さに立ち向かうテストが何を解決するのか:   プロダクトコードが「解決方法」を示すのに対して、テストは「結果」を示す。また、両者は別々に管理されるので、正解が固定された状態を保ちやすくなるどう使うか:   プロダクトコードの作成の事前もしくは事後に「これが正解だ」と示すテストを用意しておく。そのあと、プロダクトコードの改修後に同様にテストが通ること(あるいは適切に通らなくなっていること)を確認する

Slide 62

Slide 62 text

曖昧さをテストで排除する例スナップショットテスト実行結果を保持しておき、再実行時にその内容を比較する https://zenn.dev/naopusyu/articles/a52403c21d67f5 https://zenn.dev/loglass/articles/863404c8ebfd60

Slide 63

Slide 63 text

曖昧さをテストで排除する例スキーマ駆動開発 APIのレスポンス内容(=正解の形)を予め定め、実装を進める https://www.youtube.com/watch?v=W6Tt4ETODP8 https://zenn.dev/litalico/articles/re-architecting-rezept2

Slide 64

Slide 64 text

＋α   テストを通して得られるものとは

Slide 65

Slide 65 text

「コードでテストする」ことの旨味「期待通りに動くか」の検証だけなら、   人間の目と手を使っても実現できる   ⇓   「コードによるテスト」は人間の弱点を補うもの

Slide 66

Slide 66 text

人間の弱点？機械(コード)の長所？正確に作業を反復し、   同じ結果を出せる弱み探索的、想像力を要する (0->1)作業が難しいアドリブや工夫を伴う   作業を行える退屈な作業に弱い   省力化したがる(飽きる) 人間の強み機械の強み弱み弱み

Slide 67

Slide 67 text

テストを使う＝人間と機械の強みを組み合わせた協業分解し、正否を明確にされたテストは単純そのもの。これを何度も繰り返すのは、人間には苦痛となる。 ⇓ 反復し、必要なフィードバックを機械に委ねることで   人間は本質的で創造的な作業に集中できる

Slide 68

Slide 68 text

テストに慣れることで得られるものテストは「問題を切り刻む」道具になりえる ⇓ コード(とその前段にある)要求・問題の   捉え方を鍛えるのに繋がる

Slide 69

Slide 69 text

テストに慣れることで得られるものテストは「問題を切り刻む」道具になりえる ⇓ コード(とその前段にある)要求・問題の   捉え方を鍛えるのに繋がる目的(≒期待する結果)と   実装を切り離して考えるのは、   抽象的な思考能力も鍛えてくれる => 設計力

Slide 70

Slide 70 text

生産性の獲得へ能力と労力の配分を最適化できる   問題の分解・定義能力が上がる ⇓ テスト書いた方が開発が早いじゃんへ

Slide 71

Slide 71 text

1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 72

Slide 72 text

1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・   →こじ開けて始める 4. まとめ

Slide 73

Slide 73 text

なぜテストを書か(け)ないのか理想的には「書くべきだ」と感じても、書けていない ↓ 理想的でない現実があるから

Slide 74

Slide 74 text

悲報: 「明日からテストを書けるように」は難しい「テストがない」は   ハード(スキル)面の問題であると同時に、   社会学的・歴史的な問題でもある

Slide 75

Slide 75 text

テストを妨げる「◯◯がない」ハード(スキル)面の問題 • 技量や知識、経験などの個人における不足 • ツールや実行環境の導入・整備などの環境面での不足 • (既存)コードがテストをしやすい状態になっていない

Slide 76

Slide 76 text

テストを妨げる「◯◯がない」ソフト（組織・文化）面の問題 • リーダーシップを取る人がテストの重要性を理解していない • 組織・プロジェクトがテストに対して時間・予算の十分な投資がない • テストを書く慣例や風土がない

Slide 77

Slide 77 text

「書かせない」デッドロック状態「今まで書けていない」から「書きにくい」し、   「書きにくい」から「書き始めない」になる ↑↓ 「書かないと力がつかない」ので、   「書くためのハードルが下がらない」まま

Slide 78

Slide 78 text

どうすれば書けるようになるか？「書いたことがないから書けない」 ⇓ 書いていける機会を作る

Slide 79

Slide 79 text

どうすれば書けるようになるか？「書ける環境がないから書けない」 ⇓ 環境ガン無視の個人プレイでワンチャン

Slide 80

Slide 80 text

いつ書き始めるのが良いか「開発を早くする」という効果に絞れば、次の3つ 1. 新しい部分を実装し始める前 • 「こういう要素があるな」と気づいた事からテストとして「メモ」してみる 2. 既存コードへの追加・改修 • まずは「今はこう動いている」をテストに書き写しておく 3. リファクタリング • リファクタリングの前と後で「同じ結果になる」のをテストで担保する

Slide 81

Slide 81 text

環境整備がない中でテストをどう始めるか ① 「PHPUnit」だけがテストじゃない ② 書いてもgit commitしなければ自分だけの世界 ③ 自分が書いたテスト以外を「使う」

Slide 82

Slide 82 text

ヒント①   「PHPUnit」だけがテストじゃない

Slide 83

Slide 83 text

①「PHPUnit」だけがテストじゃない • PHPUnitは、PHPの自動化テスト/単体テストのデファクト • ただし、導入コストも学習コストもゼロではない • チームの理解や環境的な支援がない中では、ハードルが高くなる • であれば、無理に使わない選択もアリ。   「動かしやすいテスト」から始めても良い

Slide 84

Slide 84 text

動かしやすいテスト？ • 通常、テストコードは   「プロダクトコードとは別のエントリーポイント」で起動される • (`vendor/bin/phpunit` みたいな) • 対象とするコードの、「オブジェクトの生成方法」「使い方」を知っていれば似たようなことができる

Slide 85

Slide 85 text

自分で素朴なテストを用意してみるこんなコードが   あったとしたら

Slide 86

Slide 86 text

自分で素朴なテストを用意してみる autoload.phpだけ読み込んで、   オブジェクトをnewして、   メソッドを呼び出して、   assert()する     コードがあればOK！   必要に応じてvar_dump() なども書き加える

Slide 87

Slide 87 text

補足: assert()って？「事前/事後条件を満たすか」を検査できる仕組み。今回のような、テストの実装にも十分に流用できる詳しくは、少し前ですが、インフィニットループさんの記事がおすすめ PHP7 の assert による簡易テストはいいぞ。   https://infiniteloop.co.jp/tech-blog/2016/12/php-assertion-expectation/

Slide 88

Slide 88 text

自分で素朴なテストを用意してみるもっと愚直な感じでも   何も問題ない

Slide 89

Slide 89 text

自分で素朴なテストを用意してみるあとは、通常のPHPスクリプトとして実行

Slide 90

Slide 90 text

「生成」が複雑なコードの場合のテクニック • 例えば、依存の解決をDIコンテナで行っている場合 • 素朴な「new Hoge()」が難しい・・・・ • そんな時は、プロダクトコードの中にテストを同居させてしまう

Slide 91

Slide 91 text

プロダクトコードの中にテストを同居させてしまう今っぽいFWだと、   コンストラクタやメソッドで依存を注入しがちですよね。   そうしたオブジェクトを正しく生成するのは手間が掛かるかも知れません

Slide 92

Slide 92 text

プロダクトコードの中にテストを同居させてしまう思い切って、そのアクションの中に検査(テスト)を書いてしまう ※ もちろん、メソッドだけは別にしてもOK

Slide 93

Slide 93 text

プロダクトコードの中にテストを同居させてしまうそうすれば、   複雑な「生成」「起動」の知識がなくても、   いつも通りに動かすだけでテストができる

Slide 94

Slide 94 text

プロダクトコードの中にテストを同居させてしまうただし、コードが別ファイルで管理されている場合と違って、   保存して→蓄積していくのが難しい。。。実装中のテストに限定して適用できる方法。

Slide 95

Slide 95 text

プロダクトコードの中にテストを同居させてしまうクラスの設計や機能によっては、コンストラクタの中に埋め込むことで   検査を強制させるのも便利な方法。

Slide 96

Slide 96 text

プロダクトコードの中にテストを同居させてしまうリファクタ時には、「前のメソッドを完全コピペ」「新メソッドと結果を一致させる」などの使い方もできる

Slide 97

Slide 97 text

もっと複雑な場合: APIレスポンスをテストする • どうしてもコードとテストを同居させるのが難しい場合、E2Eのレイヤーでテストしてしまうのも手 • curlコマンドなどで「Webリクエストを実行」して、 • これはPHPからcurlでもいいし、exec()で外部コマンドを叩いてもいいし • 取得した内容に、preg_matchやjson_decodeなどで検査をかける • PostmanやIDEのHTTPツールを使うのも捗るのでおすすめ

Slide 98

Slide 98 text

もっと複雑な場合: APIレスポンスをテストする • 例えばAPIの機能改修を行う場合には・・ • 改修前に、そのエンドポイントのスナップショットを用意して • 改修後の「変わるべき場所」の検査を追加する

Slide 99

Slide 99 text

Slide 100

Slide 100 text

ヒント②   書いてもgit commitしなければ   自分だけの世界

Slide 101

Slide 101 text

② 書いてもgit commitしなければ自分だけの世界 • 書いたコードを、必ずしもpushする必要はない • 「消す前提のコード」を書いても良い • t-wadaさん「学習用テスト」 • 資産として残しておきたいなら、`.git/info/exclude` もおすすめ • 自分だけの.gitignoreみたいなもの。 • ここに学習用テストや、スニペット等をおいておくと便利になるかも

Slide 102

Slide 102 text

学習用テスト第1回　学習用テスト～学びを自動テストとして書く～ | gihyo.jp https://gihyo.jp/dev/serial/01/savanna-letter/0001

Slide 103

Slide 103 text

ヒント③   自分が書いたテスト以外を「使う」

Slide 104

Slide 104 text

③ 自分が書いたテスト以外を「使う」 • 通常のコードと同じく、   「書く」のと同じくらい「たくさん読む」ことも重要 • 普段利用しているフレームワークやライブラリのテストコードを   よく読んでみることで、一石二鳥の経験値を獲得できる • 手元で動かしてみると更に◎ • その際に、パラメータなどを書き換えてみることで実装の理解もしやすくなる • 「この値を受け取った時にどうなるんだろう」という興味本位で   弄り放題、壊し放題！なのは楽しいしオススメ

Slide 105

Slide 105 text

1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ

Slide 106

Slide 106 text

テスト書いた方が開発が早いじゃん #とはテストというツールによって   人間の不得手な部分を補う ⇓ それによって、「追加工数」以上の効率を手に入れる

Slide 107

Slide 107 text

テストはどう始めればいいか「テストを書く」のにネガティブな環境にいても、   自分の手の回る範囲だけで取り入れてみる方法はある

Slide 108

Slide 108 text

小さくても、完璧を目指さずに始めてみる力をつけるには自ら経験を積んでいくしかない。できるところからやっていけば、   できる範囲が広がっていくはず

Slide 109

Slide 109 text

本日のテーマ[再掲] 中長期的な目線ではなく、短期的な目線でも「早い」を助けるテストの考え方/使い方を知って、明日からの開発を助ける武器を増やそうトーク

Slide 110

Slide 110 text

おしまい！お付き合いいただきありがとうございました!!

Slide 111

Slide 111 text

興味を持った人向け: べりべりオススメリソース • 『TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング』   https://www.youtube.com/watch?v=Q-FJ3XmFlT8 • とにもかくにも、「テストを味方にして開発を楽にする」が全部ある動画 • 『ソフトウェア品質を高める開発者テスト改訂版アジャイル時代の実践的・効率的でスムーズなテストのやり方（高橋寿一）』   https://www.shoeisha.co.jp/book/detail/9784798176390 • 開発経験のある人が「テストってどういう感じ」に初めて触れるのに良い感じ

Slide 112

Slide 112 text

参考書籍 • 『誰のためのデザイン？増補・改訂版：認知科学者のデザイン原論』   https://www.shin-yo-sha.co.jp/book/b455574.html   『人を賢くする道具』   https://www.chikumashobo.co.jp/product/9784480511270/ • 「制約」「フィードバック」によって何が与えられるか、人間が苦手とするもの、という観点はノーマンの著作から大いに影響を受けました • 『xUnit Test Patterns: Refactoring Test Code』   https://www.informit.com/store/xunit-test-patterns-refactoring-test- code-9780132800051 • 自動テストやテストの品質(持続可能性)についての話題を扱う本ですが、"Test as Safety Net"は本トークの主要な要素の1つ(の原型)になりました