テスト書きたいけど書けてないのは何でなんだぜ

Slide 1

Slide 1 text

テスト書きたいけどテスト書きたいけど書けてないのは何でなんだぜ書けてないのは何でなんだぜ 2024-07-19 PHP勉強会神戸

Slide 2

Slide 2 text

自己紹介堂薗　伸樹（どうぞの　のぶき） @DPontaro 所属：スターフェスティバル株式会社大阪在住妻、男の子2人、犬ゲーム開発　→　Webアプリケーション登壇経験あまりないので、緊張してます

Slide 3

Slide 3 text

今日話すことテストって書いたほうがいいよねでも書けてないことが多々あるなんでだっけを掘り下げて書く意欲をあげていきたい

Slide 4

Slide 4 text

私とはじめてのテストはいいいえ

Slide 5

Slide 5 text

BDDフレームワークソシャゲのwebview画面のテストに導入されました初めて触れたテスト behat

Slide 6

Slide 6 text

ユニットテストもしたことないメンテつらいメリットがわからない結局書かなくなった初めて触れたテスト behat テストに対しての第一印象はよくなかった

Slide 7

Slide 7 text

テストの目的、メリットはいいいえ

Slide 8

Slide 8 text

リファクタリング振る舞いを変えずに、安全に変更できる品質保証バグの早期発見、修正不具合の再現（回帰テスト）ドキュメンテーションテストコード自体が仕様の説明になる設計の改善テスタブルなコードを書くことで、結果的に良い設計になる etc...

Slide 9

Slide 9 text

なんで書かないの？メリットいっぱいじゃん？

Slide 10

Slide 10 text

なんで書けてないんだっけ？はいいいえ

Slide 11

Slide 11 text

（満足いくほど）書けてないのはなぜか成功体験が足りていない自動テストの環境が整っていない時間がない

Slide 12

Slide 12 text

成功体験を積めていない労力　＜　メリット　を感じる場面が多くないのではないか最初がbehatだったので余計に。自動テストの環境が整っていない仕組みによる強制がないので、書かずとも進行してしまう開発そして仕込まれる不具合時間がない眼の前のスケジュールにアップアップで、実装と動作確認で手一杯

Slide 13

Slide 13 text

はい

Slide 14

Slide 14 text

じゃあどうしていこうねはいいいえ

Slide 15

Slide 15 text

時間がない書かないと早くはならない時間がかかるのは、道具が手に馴染んでいないアサーションモックやれることを知っていても細かい書き方覚えてなく、ググる、ジピる時間が出てきたりする書いて脳と手に刻み込む。

Slide 16

Slide 16 text

時間がないユニットテストから慣れていこう AAAパターンテストダブル（スタブ、モック、etc...）設計の原則も知っていこう（テストしやすいクラスを意識していく） S：単一責任の原則 O：オープン / クローズド原則 L：リスコフの置換原則 I：インタフェース分離の原則 D：依存関係逆転の原則

Slide 17

Slide 17 text

はい

Slide 18

Slide 18 text

自動テストの環境がないつくろう！！！新規に走り始めたり、まだ日が浅いプロジェクトはチャンス。後になればなるほど構築はしんどくなる。今すぐやろう

Slide 19

Slide 19 text

自動テストの環境がないそうはいってもCIのワークフロー作ったことないですやったことないと心理的ハードル高いよね、わかる GitHub Actions とか GitLab CI とかでやれるよだいたい似たような流れになるよワークフローが発火する条件コードのチェックアウト環境セットアップテスト用のenvファイル作成依存ライブラリのインストールテスト実行（必要に応じて）結果をどこか（slackとか）に通知

Slide 20

Slide 20 text

自動テストの環境がない claudeに聞いてみた。ざっと大まかな流れはこれで作れるので、あとは多少の試行錯誤で動かせるはず。がんばれ。

Slide 21

Slide 21 text

自動テストはあるけど、メンテされてなくて壊れてるこの場合、どうしたらいいかは私が聞きたい一旦部分的に重要なやつだけ、テスト通すようにしていくとか・・・？テスト実行時に特定のテストや、ディレクトリだけ指定するのはできるのでそうして徐々に時間をかけて改善していくレガシーコード改善ガイド、あたりを読むといい？（積読状態）たいてい密結合しまくったコードが大量でテストしづらい状態テストのためにリファクタリングしたいが、テストがないので安全にリファクタリングできないパターンそのあたりの取り組み方とかも書いてあったような気がする

Slide 22

Slide 22 text

成功体験きっとちょっとずつ積まれてるはず。思い出して。 behatのことは一旦忘れて。仕様の漏れに気づくテストパターンを考えているうちに、想定しきれてない箇所に気づくことができた。境界値テストとかやってると、まれによく出てくる本番で発生した不具合の再現をテストに書いておいた後日、別の人の機能実装時にきちんとこけてくれて同様の不具合を未然に防げた。細かい修正はサクサク回して手早く動作確認できる phpunitだと、--filter とか --group でローカルでは特定のテストだけ指定してサクサク回したりしてるやってるうちに、きれいなクラス設計も見えてくるよ

Slide 23

Slide 23 text

成功体験書いたら褒める！！他人も褒める、自分も褒める、何回でも褒めるテストを書くあなたは偉い！！！

Slide 24

Slide 24 text

ということで宣誓引き続きやっていって呼吸するようにテストかけるようになりますただ量産するでなく、費やした労力に見合った結果を引き出せるテストを作成できるようになります。

Slide 25

Slide 25 text

ご清聴ありがとうございましたもっとテスト書いていきますはい