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

PHPカンファレンス名古屋2025の発表資料です
https://fortee.jp/phpcon-nagoya-2025/proposal/436ec84b-1ab6-46a4-abb8-a29abaf8a817

Transcript

1. 『テスト書いた方が 開発が早いじゃん』を解き明かす PHPカンファレンス名古屋2025 Hideki Kinjyo GitHub: o0h / X: @o0h_ [発表用]
2. イントロ こんにちは！！ いつも楽しくテストを書いてますか？ 
3. イントロ 「でも、テストを書く時間が無いんです」 
4. イントロ 「でも、テストを書く時間が無いんです」  その分の工数が増えるじゃん
5. イントロ 「あなたが言っているのは、中長期的な話ですよね」  テスト書く方が効率良いよ
6. イントロ  [ग़య] ᴷ Meszaros, Gerard. ʰxUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) Kindle dition. ʱP20
7. イントロ 「そうじゃないんすよ」 「短いサイクルで見ても、行けるはずなんすよ」  ほら、 イニシャルコストじゃん
8. イントロ 「テストを書いていないから時間が無いんでしょ」  書いた方が 効率が上がる・楽になるよ ʁ
9. なぜなのか 
10. イントロ テストを書く時間がない人 「テスト書くような時間が無いです」 テストを書いた方が開発が早い人 「テスト書いた方が開発が早いじゃん」  こういうこと？
11. テストを書く時間がない人 「テスト書くような時間が無いです」 テストを書いた方が開発が早い人 「テスト書いた方が(開発が)早いじゃん」 イントロ きっと何かの ギャップがあるぞ 
12. テストを書く時間がない人 「テスト書くような時間が無いです」 テストを書いた方が開発が早い人 「テスト書いた方が(開発が)早いじゃん」 イントロ きっと何かの ギャップがあるぞ  これを解き明かす！
13. 本日のテーマ 中長期的な目線ではなく、 短期的な目線でも「早い」を助ける テストの考え方/使い方を知って、 明日からの開発を助ける武器を増やそうトーク 
14. 本日のテーマ 🙅 良いテストを書きましょう 🙅テストでプロダクトの価値を高めましょう 🙅組織でテストを書ける土壌・文化を築きましょう ⇓ 「保守」「持続可能性」の話ではなくて・・ 
15. 本日のテーマ 🙆「テストを書く」ことで何が助けられるのか 🙆「でもウチはテスト書いてなくて」で諦めない ⇓ 個々人の、目の前の「早さ」を獲得するヒント 
16. 自己紹介 ✔ 紹介済み • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏 : @o0h_ • 好きなFWはCakePHP • アイコンは美味しい鮭親子丼の写真です • これで3年連続・4度目の名古屋です 
17. おしながき 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ 
18. おしながき 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ  (トークの範囲外)
19. おしながき 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ  ask the speakerで！ 懇親会で！
20. おしながき 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ  ask the speakerで！ 懇親会で！ 話したい！お願いします！
21. 注意 • この発表中では、開発者自身が作成する、実行可能なコードとして記 述されるソフトウェアテストのことを簡易的に「テスト」と呼びます • 手動や目検で「合否」を判定するテストは含みませんが、必ずしも起 動や実行前のセットアップが完全に自動化されているものには限定し ません 
22. 1. プログラミング難しいね → 現実(物理)と比べて無秩序な世界！ 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ
23. (楽をしたくなるほどに) プログラミングは難しい作業 
24. プログラミング難しい三選 ① プログラミングは複雑 ② プログラミングは緩慢 ③ プログラミングは曖昧 
25. 難しさ① <複雑さ> 考えることが多くて、とっても複雑
26. ① 複雑さ: 考えることが多くて、とっても複雑 プログラミングは、 複数の計算・処理を組み合わせる活動。 様々なレイヤーを行ったり来たりしながら、 同時多発的に作業を行う。忙しい！ 
27. ① 複雑さ: 考えることが多くて、とっても複雑 
28. ① 複雑さ: 考えることが多くて、とっても複雑  「有効なユーザー名」の ルールを確認しなきゃ 判定は正規表現？ バリデーションのラ イブラリって入ってるんだっ け？ このルールを使うのはここ だけ？ 失敗したらfalse? 例外投げる？ 事前にチェックされ てるのは？nullも来る？string だけ？ メソッドを切るのが良いのか な、インラインでいいのかな 引数名はどうしよう 違反内容はどこまで記述する？ メッセージはUIにそのまま出 される？別で解釈される？ 文言、ですます長だっけ？
29. ① 複雑さ: 考えることが多くて、とっても複雑  「有効なユーザー名」の ルールを確認しなきゃ 判定は正規表現？ バリデーションのラ イブラリって入ってるんだっ け？ このルールを使うのはここ だけ？ 失敗したらfalse? 例外投げる？ 事前にチェックされ てるのは？nullも来る？string だけ？ メソッドを切るのが良いのか な、インラインでいいのかな 引数名はどうしよう 違反内容はどこまで記述する？ メッセージはUIにそのまま出 される？別で解釈される？ 文言、ですます長だっけ？ ビジネス 「ビジネスルール」、「コーディングガイドライン」、 「他の箇所との一貫性」、「設計レベルの判断」、「細 やかな可読性や堅牢性」etc.. ⇑ 様々なレイヤーの判断が押し寄せる
30. 難しさ② <緩慢さ> 制約が「ソフト」で、 逸脱や違反に対して鈍感
31. ② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 プログラミングは、 論理的な世界で成り立つ活動。 物理の世界にあるものと違って、 簡単に「逸脱」を起こしやすい。 
32. ② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 ★物理の世界なら？  みんなに ケーキを切り分けよう！ 多くて8人くらいかな
33. ② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感 ★物理制約から開放された自由な世界───  $me->cut($cake, -10000) みんなに ケーキを切り分けよう！
34. ② 緩慢さ: 制約が「ソフト」で、逸脱や違反に対して鈍感  $me->cut($cake, -10000) みんなに ケーキを切り分けよう！ ビジネス 現実なら「意識する前から存在していた法則」が 物理世界に留まるようにガイドするが、 制約はプログラマが恣意的に与える必要がある。 ⇓ 「自然」がなく、常に思考に負荷が掛かる
35. 難しさ③ <曖昧さ> 実現したいことに対して、 実装方法や完成度が曖昧
36. ③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 プログラミングは、 要求や目的に沿ってコードへ翻訳する活動。 「問い」があっても 必ずしも「解法」の形を規定せず、 正解や完成の度合いも明確になりにくい。 
37. ③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」 
38. ③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」  まずは牛乳や卵が買える場 所に行かないと お金が要るな、 財布を持っていこう (現実では)問題が出された時点で、凡その「解き方」が決まる。
39. ③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」  牛乳は ハードコーディングで良い？ 卵はキャッシュから使い回 せる？だめ？ (プログラミングにおいては)問題が明確になりにくく、 解法は更に多くのバリデーションを発生させる 買い物に行くのはログイン が必要？匿名で良い？
40. ③ 曖昧さ: 実現したいことに対して、実装方法や完成度が曖昧 Q. 「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」  牛乳は ハードコーディングで良い？ 卵はキャッシュから使い回 せる？だめ？ (プログラミングにおいては)問題が明確になりにくく、 解法は更に多くのバリデーションを発生させる 買い物に行くのはログイン が必要？匿名で良い？ ビジネス 「現実」から「論理」に翻訳するということは、 本質的に「形を変えて表現する」作業となる。 出題の意図と回答が、"==="で結びつかない世界。 ⇓ ゴールを「固定」しないと完成に到達しない
41. (楽をしたくなるほどに) プログラミングは難しい作業 
42. (楽をしたくなるほどに) プログラミングは難しい作業 ⇓ 気づかない内に め〜〜〜っちゃ負荷が掛かっていそう！ 
43. プログラミングの難しさに立ち向かう ＼朗報／ テストなるものが、 これらの困難を緩和する助けとなってくれるはず 
44. 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ
45. 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ →ちょっとした秩序として考えてみる 3. でもテスト書ける気がしなくて・・ 4. まとめ
46. そもそもテストってなんだ？ (色々な定義や観点があるが) めっちゃ単純な言い方をすれば、 動かしてみて→答え合わせする一式のセット 
47. そもそもテストってなんだ？ • `add(1, 100)` したら `(int)101` が返ってくるとか • ログイン状態で`/user/mypage` を開くと自分の名前が表示されるとか • 退会処理バッチを回したらユーザーの投稿が削除されるとか なんでも良いです！ 
48. テストを使って困難に立ち向かう ① 複雑さに立ち向かうテスト ② 緩慢さに立ち向かうテスト ③ 曖昧さに立ち向かうテスト 
49. 攻略① 複雑さに立ち向かうテスト
50. 複雑さに立ち向かうテスト なにが問題だったか: 1つの問題(仕様)を解くために、多様・雑多なステップが必要なことが 「複雑さ」の問題だった どうして難しいのか: 複雑な問題に対する王道的なアプローチは「分割統治」。細かく分解し て、個別的に対処するべき。 ただし、プロダクトコードでは無駄なステップを増やしたり過度な分解 を適用することは難しい・・・ 
51. 複雑さに立ち向かうテスト テストが何を解決するのか: プロダクトコードと違い、テスト(コード)は「冗長」を受け入れて「解 剖」「複眼・比較」的な態度を歓迎する。 よって、プロダクトコードと違って「問題を分解し、少しずつ確かめ る」ための武器となる どう使うか: 分解した、小さな「問題」「期待(正解)」をたくさん書いていく 
52. 複雑さをテストで易しくする例  複数の要素からなる配列を受け取る コレクションクラス `avg()`メソッドで、全要素の平均を返す 平均ってことは、 まずは全部を足して 要素数で割ればOK？ 要素が0個の場合も 考えないと int/floatだけとも 限らないよな PHP_INT_MAX超えるかもしれない nullはどう扱おうかな
53. 複雑さをテストで易しくする例  平均ってことは、 まずは全部を足して 要素数で割ればOK？ Collection::fromArray([1, 10, 10])->avg() === 7 function avg(): float { $total = array_sum($this->items); $count = count($this->items); return $total / $count; }
54. 複雑さをテストで易しくする例  要素が0個の場合も 考えないと Collection::fromArray([])->avg() === null; $count = count($this->items); if ($count === 0) { return null; }
55. 複雑さをテストで易しくする例  int/floatだけとも 限らないよな try { Collection::fromArray([1, 'a'])->avg(); } catch (UnexpectedValueException) { ɾɾɾ if (!array_all( $this->items, fn($v) => is_float($v) || is_int($v), )) { throw new UnexpectedException; }
56. 攻略② 緩慢さに立ち向かうテスト
57. 緩慢さに立ち向かう なにが問題だったか: 「そんな使い方しないでよ〜・・・」といった常識では考えられない出 来事でも、明示されない限りは起き得てしまう。 「決められていない事」に対し、ソフトウェアはフィードバックを出さ ないのが問題だった どうして難しいのか: 人間はどうしても「うっかり」を起こすし、「完全な視野」を持たない。 思考に限界がある。もし制約とフィードバックがないのであれば、誤り に気づくことはかなり難しい 
58. 緩慢さに立ち向かう テストが何を解決するのか: テストを書いて「合格・不合格」を明確に判定させることで、強い「制 約」として利用できる。そうした制約を、1つずつ積み重ねていくこと で、うっかり漏らしの対抗策とする。 どう使うか: 「これは違反である」という使い方を再現したテストを作り、プロダク トコードが「拒絶」することを確かめておく 
59. 緩慢さをテストで取り締まる例  求人案件の登録で、 提示年収を管理する機能 年収って言ったら 300ドングリ以上だよね 最近はドングリの代わりに ハマグリを渡す会社も多いみたいだし、 対応して対応しておこう
60. 緩慢さをテストで取り締まる例  求人案件の登録で、 提示年収を管理する機能 年収って言ったら 300ドングリ以上だよね 最近はドングリの代わりに ハマグリを渡す会社も多いみたいだし、 対応して対応しておこう 偽ドングリを 渡そうとしたら駄目だぞ 明らかに 会社の資本力と見合っていない ドングリやハマグリを受け付けるべきでない ハマグリを使うなら 予め「ハマグリ輸送手段」が 設定されているべきだ
61. 攻略③ 曖昧さに立ち向かうテスト
62. 曖昧さに立ち向かう なにが問題だったか: 仕様や要求は自然言語で、人間が読みやすいように書かれる。他方でプ ログラミング的な挙動については必ずしも厳密に示されない。翻訳的な 作業が発生するのが問題だった どうして難しいのか: プロダクトコード(= 変更され続けるもの)だけが 「正解を知っている」になると、答え合わせの方法がなくなる 
63. 曖昧さに立ち向かう テストが何を解決するのか: プロダクトコードが「解決方法」を示すのに対して、テストは「結果」 を示す。また、両者は別々に管理されるので、正解が固定された状態を 保ちやすくなる どう使うか: プロダクトコードの作成の事前もしくは事後に「これが正解だ」と示す テストを用意しておく。そのあと、プロダクトコードの改修後に同様に テストが通ること(あるいは適切に通らなくなっていること)を確認する 
64. 曖昧さをテストで排除する例 スナップショットテスト 実行結果を保持しておき、再実行時にその内容を比較する  https://zenn.dev/naopusyu/articles/a52403c21d67f5 https://zenn.dev/loglass/articles/863404c8ebfd60
65. 曖昧さをテストで排除する例 スキーマ駆動開発 APIのレスポンス内容(=正解の形)を予め定め、実装を進める  https://www.youtube.com/watch?v=W6Tt4ETODP8 https://zenn.dev/litalico/articles/re-architecting-rezept2
66. ＋α テストを通して得られるものとは
67. 「コードでテストする」ことの旨味 「期待通りに動くか」の検証だけなら、 人間の目と手を使っても実現できる ⇓ 「コードによるテスト」は人間の弱点を補うもの 
68. 人間の弱点？機械の長所？ コード(機械)の強み 正確に作業を反復し、 同じ結果を出せる 弱み 探索的、想像力を要する (0->1)作業が難しい  人間の強み アドリブや工夫を伴う 作業を行える 弱み 退屈な作業に弱い 省力化したがる(飽きる)
69. テストを使う＝人間と機械の強みを組み合わせた協業 分解し、正否を明確にされたテストは単純そのもの。 これを何度も繰り返すのは、人間には苦痛となる。 ⇓ 反復し、必要なフィードバックを機械に委ねることで 人間は本質的で創造的な作業に集中できる 
70. テストに慣れることで得られるもの テストは「問題を切り刻む」道具になりえる ⇓ コード(とその前段にある)要求・問題の 捉え方を鍛えるのに繋がる 
71. テストに慣れることで得られるもの テストは「問題を切り刻む」道具になりえる ⇓ コード(とその前段にある)要求・問題の 捉え方を鍛えるのに繋がる  目的(≒期待する結果)と 実装を切り離して考えるのは、 抽象的な思考能力も鍛えてくれる => 設計力
72. 生産性の獲得へ 能力と労力の配分を最適化できる 問題の分解・定義能力が上がる ⇓ テスト書いた方が開発が早いじゃんへ 
73. 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ
74. 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ →こじ開けて始める 4. まとめ
75. なぜテストを書か(け)ないのか 理想的には「書くべきだ」と感じても、書けていない ↓ 理想的でない現実があるから 
76. 悲報: 「明日からテストを書けるように」は難しい 「テストがない」は ハード(スキル)面の問題であると同時に、 社会学的・歴史的な問題でもある 
77. テストを妨げる「◯◯がない」 ハード(スキル)面の問題 • 技量や知識、経験などの個人における不足 • ツールや実行環境の導入・整備などの環境面での不足 • (既存)コードがテストをしやすい状態になっていない 
78. テストを妨げる「◯◯がない」 ソフト（組織・文化）面の問題 • リーダーシップを取る人のテストの重要性を理解していない • 組織・プロジェクトがテストに対して時間・予算の十分な投資がない • テストを書く慣例や風土がない 
79. 「書かせない」デッドロック状態 「今まで書けていない」から「書きにくい」し、 「書きにくい」から「書き始めない」になる ↑↓ 「書かないと力がつかない」ので、 「書くためのハードルが下がらない」まま 
80. どうすれば書けるようになるか？ 「書いたことがないから書けない」 ⇓ 書いていける機会を作る 
81. どうすれば書けるようになるか？ 「書ける環境がないから書けない」 ⇓ 環境ガン無視の個人プレイでワンチャン 
82. いつ書き始めるのが良いか 「開発を早くする」という効果に絞れば、次の3つ 1. 新しい部分を実装し始める前 • 「こういう要素があるな」と気づいた事からテストとして「メモ」してみる 2. 既存コードへの追加・改修 • まずは「今はこう動いている」をテストに書き写しておく 3. リファクタリング • リファクタリングの前と後で「同じ結果になる」のをテストで担保する 
83. 環境整備がない中でテストをどう始めるか ① 「PHPUnit」だけがテストじゃない ② 書いてもgit commitしなければ自分だけの世界 ③ 自分が書いたテスト以外を「使う」 
84. ヒント① 「PHPUnit」だけがテストじゃない
85. ①「PHPUnit」だけがテストじゃない • PHPUnitは、PHPの自動化テスト/単体テストのデファクト • ただし、導入コストも学習コストもゼロではない • チームの理解や環境的な支援がない中では、ハードルが高くなる • であれば、無理に使わなくても 「動かしやすいテスト」から始めても良い 
86. 動かしやすいテスト？ • 通常、テストコードは 「プロダクトコードとは別のエントリーポイント」で起動される • (`vendor/bin/phpunit` みたいな) • 対象とするコードの、「オブジェクトの生成方法」「使い方」を知っ ていれば似たようなことができる 
87.  namespace App\Util; class Collection { public function avg() { } } 自分で素朴なテストを用意してみる こんなコードが あったとしたら
88.  use App\Util\Collection; require '../vendor/autoload.php'; $obj = new Collection([1, 10, 22]); assert($obj->avg() === 11); 自分で素朴なテストを用意してみる autoload.phpだけ読み込 んで、 オブジェクトをnewして、 メソッドを呼び出して、 assert()する コードがあればOK！ 必要に応じてvar_dump() なども書き加える。
89.  補足: assert()って？ 「事前/事後条件を満たす か」を検査できる仕組み。 今回のような、テストの実 装にも十分に流用できる。 詳しくは、少し前ですが、 インフィニットループさん の記事がおすすめ。 PHP7 の assert による簡易テストはいいぞ。 https://infiniteloop.co.jp/tech-blog/2016/12/php-assertion-expectation/
90.  use App\Util\Collection; require '../vendor/autoload.php'; $obj = new Collection([1, 10, 22]); if ($obj->avg() !== 11) { throw new \Exception('failedʂ'); } 自分で素朴なテストを用意してみる もっと愚直な感じでも 何も問題ない。
91.  自分で素朴なテストを用意してみる あとは、通常のPHPスクリ プトとして実行 $ php '/tests/collection_test.php';
92. 「生成」が複雑なコードの場合のテクニック • 例えば、依存の解決をDIコンテナで行っている場合 • 素朴な「new Hoge()」が難しい・・・・ • そんな時は、プロダクトコードの中にテストを同居させてしまう 
93.  public function registerAction( Request $request, UserSaveService $service, ) { // ԿΒ͔ͷॲཧ } プロダクトコードの中にテストを同居させてしまう 今っぽいFWだと、 コンストラクタやメソッ ドで依存を注入しがちで すよね
94.  public function registerAction( Request $request, UserSaveService $service, ) { // ԿΒ͔ͷॲཧ assert(ɾɾɾɾ); } プロダクトコードの中にテストを同居させてしまう 思い切って、そのアク ションの中に検査(テス ト)を書いてしまう ※ もちろん、メソッドだ けは別にしてもOK
95.  public function registerAction( Request $request, UserSaveService $service, ) { // ԿΒ͔ͷॲཧ assert(ɾɾɾɾ); } プロダクトコードの中にテストを同居させてしまう そうすれば、 複雑な「生成」「起動」 の知識がなくても、 いつも通りに動かすだけ でテストができる
96.  public function registerAction( Request $request, UserSaveService $service, ) { // ԿΒ͔ͷॲཧ assert(ɾɾɾɾ); } プロダクトコードの中にテストを同居させてしまう ただし、コードが別ファ イルで管理されている場 合と違って、 保存して→蓄積していく のが難しい。。。 実装中のテストに限定し て適用できる方法。
97.  public function __construct($items) { $this->items = (array)$items; assert($this->avg() === 12); } プロダクトコードの中にテストを同居させてしまう クラスの設計や機能に よっては、コンストラク タの中に埋め込むことで 検査を強制させるのも便 利な方法。
98.  public function __construct($items) { $this->items = (array)$items; assert( $this->f1() === $this->f2() ); } プロダクトコードの中にテストを同居させてしまう リファクタ時には、「前 のメソッドを完全コピ ペ」「新メソッドと結果 を一致させる」などの使 い方もできる
99. もっと複雑な場合: APIレスポンスをテストする • どうしてもコードとテストを同居させるのが難しい場合、E2Eのレイ ヤーでテストしてしまうのも手 • curlコマンドなどで「Webリクエストを実行」して、 • これはPHPからcurlでもいいし、exec()で外部コマンドを叩いてもいいし • 取得した内容に、preg_matchやjson_decodeなどで検査をかける • PostmanやIDEのHTTPツールを使うのも捗るのでおすすめ 
100. もっと複雑な場合: APIレスポンスをテストする • 例えばAPIの機能改修を行う場合には・・ • 改修前に、そのエンドポイントのスナップショットを用意して • 改修後の「変わるべき場所」の検査を追加する  $actualResponse = file_get_contents('http://localhost/hoge'); $oldResponse = file_get_contents('old_response.json); // ͍͍ͬͯ͡ͳ͍৔ॴ͕ਖ਼ؚ͘͠·Ε͍ͯΔ͜ͱΛ͔֬ΊΔ assert(empty(array_diff( json_decode($oldResponse, true), json_decode($actualResponse, true), ));
101. もっと複雑な場合: APIレスポンスをテストする • 例えばAPIの機能改修を行う場合には・・ • 改修前に、そのエンドポイントのスナップショットを用意して • 改修後の「変わるべき場所」の検査を追加する  // ৽͘͠ੜ΍ͨ͠ϑΟʔϧυͷ֬ೝ assert(json_decode($actualResponse, true)['aaa'] === 'abc');
102. ヒント② 書いてもgit commitしなければ 自分だけの世界
103. ② 書いてもgit commitしなければ自分だけの世界 • 書いたコードを、必ずしもpushする必要はない • 「消す前提のコード」を書いても良い • t-wadaさん「学習用テスト」 • 資産として残しておきたいなら、`.git/info/exclude` もおすすめ • 自分だけの.gitignoreみたいなもの。 • ここに学習用テストや、スニペット等をおいておくと便利になるかも 
104. 学習用テスト  第1回　学習用テスト ～学びを自動テストとして書く～ | gihyo.jp https://gihyo.jp/dev/serial/01/savanna-letter/0001
105. ヒント③ 自分が書いたテスト以外を「使う」
106. ③ 自分が書いたテスト以外を「使う」 • 通常のコードと同じく、 「書く」のと同じくらい「たくさん読む」ことも重要 • 普段利用しているフレームワークやライブラリのテストコードを よく読んでみることで、一石二鳥の経験値を獲得できる • 手元で動かしてみると更に◎ • その際に、パラメータなどを書き換えてみることで実装の理解もしやすくなる • 「この値を受け取った時にどうなるんだろう」という興味本位で 弄り放題、壊し放題！なのは楽しいしオススメ 
107. 1. プログラミング難しいね 2. テストって何？友達になったら役立つの？ 3. でもテスト書ける気がしなくて・・ 4. まとめ
108. テスト書いた方が開発が早いじゃん #とは テストというツールによって、 人間の不得手な部分を補う。 ⇓ それによって、「追加工数」以上の効率を手に入れる 
109. テストはどう始めればいいか 必ずしも環境が「テストを書く」のにネガティブでも、 自分の手の回る範囲だけでも取り入れてみる方法はある 
110. 小さくても、完璧を目指さずに始めてみる 力をつけるには自ら経験を積んでいくしかない。 できるところからやっていけば、 できる範囲が広がっていくはず 
111. 本日のテーマ[再掲] 中長期的な目線ではなく、 短期的な目線でも「早い」を助ける テストの考え方/使い方を知って、 明日からの開発を助ける武器を増やそうトーク 
112. おしまい！ お付き合いいただき ありがとうございました!!
113. 興味を持った人向け: べりべりオススメリソース • TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング https://www.youtube.com/watch?v=Q-FJ3XmFlT8 • とにもかくにも、「テストを味方にして開発を楽にする」が全部ある動画 • ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実 践的・効率的でスムーズなテストのやり方（高橋 寿一）｜翔泳社の本 https://www.shoeisha.co.jp/book/detail/9784798176390 • 開発経験のある人が「テストってどういう感じ」に初めて触れるのに良い感じ