単体テストを書かない技術 #phpcon_odawara

Transcript

1. 単体テストを書かない技術 PHPカンファレンス小田原2024 Hideki Kinjyo GitHub: o0h / X: @o0h_ [公開用]

   v1.0.0

2. 自己紹介 • 金城秀樹 / きんじょうひでき • GitHub:@o0h / Twitter:@o0h_ •

   好きなFWはCakePHP • アイコンは 美味しい鮭親子丼の写真です

3. 今日のお話！

4. たのしみどころ！👏 ぺちこん小田原トークのたのしみどころ【全31本】｜PHPカンファレンス小田原 https://note.com/phpcon_odawara/n/n10e3291b5725

5. ンッ！？

6. 分かる

7. 同じことを思ったんですよね • 六本木某社、とある新規PJ • 謎にすごい人がデザインをリード • クリーンアーキテクチャ、モジュラモノリス─── • そうした技術選定が社内では(多分)初 •

   機が熟した〜感？とか、まぁ諸々あったんだと思います

8. 同じことを思ったんですよね 会話: • 私「どうっスカ！新しいPJ！」 • 謎にすごい人「大変だけど、頑張りながらやってるよ〜」

9. 同じことを思ったんですよね 会話: • 私「やっぱりすげ〜んスカ！アーキテクチャ！違い、どッスカ！」 • 私「クラスは増えるけど、コードも読みやすくて、テストも書きやす いんだろうな〜。いいな〜、憧れるッス！！」

10. 同じことを思ったんですよね 謎にすごい人 「1周して、テストとか必要なくなる感じがしてきてる」

11. 同じことを思ったんですよね 謎にすごい人 「1周して、テストとか必要なくなる感じがしてきてる」 ʂ

12. ─そこからn年

13. 今日に至る

14. 今回の『「ンッ！？」と目を引くタイトル』は 原体験に立ち返るもの

15. おしながき 1.ドクトリン: テストに大事なこと、なぜ書くのか 2.戦略: 「書かない」ために必要なこと 3.戦術: 「書かない」ために使うもの 4.大事なおしらせ 

16. 1. ドクトリン: テストに大事なこと、なぜ書くのか 2. 戦略: 「書かない」ために必要なこと 3. 戦術: 「書かない」ために使うもの 4.

    大事なおしらせ

17. 「単体テストを書かない」 stands for 書かない ≠ サボる ⇓ 「十分な」状態を保ちつつ、削る 

18. 書かない ≠ サボる ⇓ 「十分な」状態を保ちつつ、削る 「単体テストを書かない」 stands for 「十分な」状態を保ちつつ、削る 「何ができれば」を知る必要がある

    「何のために」が決める 

19. 「単体テスト」 is for それでは、単体テストをすることで何を成し遂げたいのでしょうか？ その答えは、ソフトフェア開発プロジェクトの成長を持続可能なもの にする、ということです。 (୯ମςετʹؔ͢Δهड़) [ग़య] ᴷ Vladimir

    Khorikov (ஶ), ਢాஐ೭ (຋༁) ୯ମςετͷߟ͑ํ/࢖͍ํ P29 ※ ڧௐ͸εϥΠυஶऀʹΑΔ 

20. 「単体テスト」 is for プログラムをテストするときは、そのプログラムになんらかの価値を 付加することになる. テストによって価値を付加するとは、プログラ ムの品質・信頼性を向上させることである. プログラムの信頼性を向 上させるとは、エラーをみつけ, それをとりのぞくことである.

    (ιϑτ΢ΣΞςετʹؔ͢Δهड़) [ग़య] ᴷ Glenford J. Myers (ஶ), দඌ ਖ਼৴ (຋༁) ιϑτ΢ΣΞɾςετͷٕ๏ ୈ2൛ P6 ※ ิ଍͸εϥΠυஶऀʹΑΔ 

21. コードは「自然と腐る」

22. 単体テストが何故「寿命を伸ばす」のか 期待する挙動の明瞭化 発見を助ける

23. 「単体テスト」 is for

24. What it is for is NOT「単体テスト」 1番のコアはここであり

25. What it is for is NOT「単体テスト」 コアを支える 方針が存在し

26. What it is for is NOT「単体テスト」 技術詳細は教条ではない

27. 単体テスト(あるいはそれ以外の何か)のドクトリン 「エントロピーの増大」に抵抗する ⇑ 複雑さや曖昧さを減らす

28. 単体テスト(あるいはそれ以外の何か)のドクトリン ここを削ぎ落とせればOK 単体テスト以外で(も)・・ね！

29. 1. ドクトリン: テストに大事なこと、なぜ書くのか 2. 戦略: 「書かない」ために必要なこと 3. 戦術: 「書かない」ために使うもの 4.

    大事なおしらせ

30. 「単体テストを書かない」ために必要なこと 単体テストがなくても「十分」なコードにする 単体テスト以外の方法で「十分」を得る

31. 「単体テストを書かない」ために必要なこと 単体テストの仕事は 「入力」に対して「出力」を試し、欠陥を暴くこと ⇓ 「試さなければならないような入力」を減らせば 無用な仕事となる

32. 「単体テストを書かない」ために必要なこと 単体テストの仕事は 「入力」に対して「出力」を試し、欠陥を暴くこと ⇓ 「試さなければならないような入力」を減らせば 無用な仕事となる この「数」「広さ」が可能性の大きさ コード自体の持つ可能性を狭める 「入力」に対して「出力」 ⇓

    「試さなければならないような入力」を減らせ

33. 日常会話で例えるなら 曖昧なプリンの例 • 「冷蔵庫にプリンあるよ〜」 • 「えっ！食べていいの？」 // 権限チェック • 「そのプリンは賞味期限まだ過ぎてない？」

    // バリデーション • 「夕食の直前にも食べて良いプリン？」 // バリデーション • 「最近、カロリー気にしてるんだけど食事制限内？」 // バリデーション • いただきま〜す！

34. 日常会話で例えるなら 自己チェック機能を備えたプリンの例 • 「冷蔵庫にゼロカロリーで、食べてもお腹に溜まらない、新鮮なプリ ンあるよ〜」 • 「えっ！食べていいの？」 // 権限チェック •

    いただきま〜す！

35. 可能性について: shin1x1さんの「制約の力」 https://speakerdeck.com/shin1x1/restricting-states 

36. 可能性について: shin1x1さんの「制約の力」 https://speakerdeck.com/shin1x1/restricting-states 

37. 曖昧さについて: t-wadaさんの「予防に勝る防御なし」 https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022 

38. 曖昧さについて: t-wadaさんの「予防に勝る防御なし」 https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022 

39. コードから可能性を減らすために 自分自身が「何者であるか」を 熟知したコードを追求する

40. • Userを取得できてい ること • Userのuuidプロパ ティが指定した値と 同じであること • レコードが存在しな いuuidにはfalseを返

    すこと どんなテストを書きたい？

41. • $uuidがstringである • $uuidが16進数表記と ハイフンしか含まな いこと • $uuidが規定された文 字数の規定されたグ ループからなること

    • $uuidが大文字でも小 文字でも同じとみな せること どんなテストを書きたい？

42. • Userを取得できてい ること • Userのuuidプロパ ティが指定した値と 同じであること 返り値の型宣言がつい ていれば、テストしな くてもErrorになる(保

    証される)

43. • $uuidがstringである • $uuidが16進数表記とハ イフンしか含まないこと • $uuidが規定された文字 数の規定されたグループ からなること •

    $uuidが大文字でも小文 字でも同じとみなせるこ と • 渡された時点で有効な データであることが保 証されている

44. 曖昧さを減らすためのヒント「概念」

45. 「名は体を表す」ようにコードを書く 本質や特性を選りすぐり、固めたものが「概念」 ⇕ 曖昧さとの対極であり、可能性を狭める

46. 「名は体を表す」ようにコードを書く 本質や特性を選りすぐり、固めたものが「概念」 ⇓ 曖昧さとの対極であり、可能性を狭める 可能性が減る =「テストして否定しないといけない」事が減る

47. 「名は体を表す」ようにコードを書く 本質や特性を選りすぐり、固めたものが「概念」 ⇓ 曖昧さとの対極であり、可能性を狭める ⇓ 埋もれている概念に名前を与え、システムの制約にする 可能性が減る =「テストして否定しないといけない」事が減る

48. 関連する特性が集合し意味を持つ所に名前を与える 自己チェック機能を備えたプリンの例 • 「冷蔵庫にゼロカロリーで、食べてもお腹に溜まらない、新鮮なプリ ンあるよ〜」 • 「えっ！食べていいの？」 // 権限チェック •

    いただきま〜す！ 命名「アンチ・ギルティ・プリン」 流通可能で一意な概念となる(ユビキタス)

49. 単体テストは「本質」に意識を向ける 単体テストでは 対象が「何をしたいか」を見抜き、表現する

50. • 価格通りの商品を1つ 取得するメソッド • 期待するProductが取 得できているかを検 査している

51. • 価格通りの商品を1つ 取得するメソッド • 期待するProductが取 得できているかを検 査している 価格だけが「期待する こと」であるはず それ以外は書かなくて

    良いテストコード

52. 提案: 新しいスタンス 「単体テストを書いた」に甘えてない？ ⇓ テストコードに「君は何でココにいるんだい」と 5回は問いかけてみる姿勢を持つ

53. 1. ドクトリン: テストに大事なこと、なぜ書くのか 2. 戦略: 「書かない」ために必要なこと 3. 戦術: 「書かない」ために使うもの 4.

    大事なおしらせ

54. 1. ドクトリン: テストに大事なこと、なぜ書くのか 2. 戦略: 「書かない」ために必要なこと 3. 戦術: 「書かない」ために使うもの 4.

    大事なおしらせ

55. コード自体の「セルフ制約」を高めるデザイン • 足し算の発想 • 関連する要素を集めて、1つの「概念」に固める • ゼロカロリーで、食べてもお腹に溜まらない、新鮮なプリン => アンチ・ギルティ・プリン(と呼べるかもしれない) •

    引き算の発想 • 既に実在し、形を持っている(ように見える)ものに引っ張られすぎず、 本質を削り出す • 「いつも親切で差し入れとかをくれる田中先輩」が好きなのではなく、 「お菓子をくれる人」ロールを必要としているだけかもしれない

56. コード自体の「セルフ制約」を高めるデザイン • 足し算の発想 => 豊富な表現力を持つ型 • 値オブジェクト • DTO •

    引き算の発想 => 本質的な(=無駄を削ぎ落とした)型 • 具象クラスよりInterface • 「コードの流れ的に、実際に渡ってくるデータ」より「用のある振る舞い」 • ex) `UserEntityCollection` ではなく `Countable` なだけかもしれない

57. 「ﾁﾗｯ」ではなく「ガチ制約」に落とし込む • 型を「制約」に • 「そういう意味を匂わせる変数名」よりも型宣言を • 静的解析による型検査 • + CIやIDE上で「真の制約となる」ことが大事

    • assert()の利用 • 「コメントで説明する」ではなく「表明で落とす」ようにする

58. 本質の追求を怠らない • 「埋もれている概念」の探求 • 会話の中で「意味を確認」した内容を「仕様」として • 「仕様」の集合に名前をつけて「概念」に持っていく • 静的なバリデーションは「型」化を検討 •

    バリデーションしている内容 ≒ 仕様 • 「AでありBでありCであるX」は、「Y」という概念が埋もれていないか？ • 動的なチェック(=「DB内に重複がある」などの状態)は、概念化が難しそう

59. 考え方 • 契約プログラミング • 偶発的プログラミング(を避ける) • 攻撃的プログラミング • 単一責任の原則 •

    セキュア・バイ・デザイン[書籍]

60. 1. ドクトリン: テストに大事なこと、なぜ書くのか 2. 戦略: 「書かない」ために必要なこと 3. 戦術: 「書かない」ために使うもの 4.

    大事なおしらせ

61. まとめ 「単体テストを書かない技術」とは 「コード自身に豊かに語らせる技術」

62. ふりかえり 「テストとか必要なくなる感じ」は、 確かに存在する！？ ⇓ より「ちゃんと意味のあるコード」に向き合い、 目指した先にある話・・・なのかな？(感想)

63. ふりかえり 意味のあるコードを書く = 無駄をなくす、不足もなくす、十分なコードを書く

64. 大事なお知らせ 埋もれている「概念」「本質」を救っていく ⇑ テストコードの「煩雑さ」は不吉な臭い 会話、要件詰めの中での「煩雑さ」は不吉な臭い

65. やっていきたいこと: たくさん話しまくる 対話を積み重ね、概念に気づいていく ⇑ ユーザーやチームなどの「人」との対話は勿論、 単体テストは「コードとの対話」という側面もある

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