Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
テスト書きたいけど 書けてないのは 何でなんだぜ
Search
DPon
July 20, 2024
Programming
210
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
テスト書きたいけど 書けてないのは 何でなんだぜ
DPon
July 20, 2024
More Decks by DPon
See All by DPon
TiDBのアーキテクチャから学ぶ分散システム入門 〜MySQL互換のNewSQLは何を解決するのか〜 / tidb-architecture-study
dznbk
1
570
『自分なんかが…』を超える。 プロポーザル提出までの心理的ハードルの外し方 / proposal-output
dznbk
1
2.3k
つよつよな人の理解の早さを理解する
dznbk
0
200
OpenSearchでレガシーな検索処理の大幅改善をやってやろう
dznbk
2
1.2k
php-fpmのプロセスをコントロールする
dznbk
0
48
Other Decks in Programming
See All in Programming
AWSに止められる覚悟してますか?
morizo_1984
2
530
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
150
CodeRabbitの効果検証と過ごしてみた3ヶ月
armondando
0
230
外から家のPCの電源入れたい!をPHPで解決する
kawashimo0
1
130
C#の現在地 進化の歴史と、AI時代の.NET Everywhere
neuecc
5
5.1k
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
740
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
1k
コードレビューのボトルネックを"する側"と"される側"の両面から解消する
yub0n
2
1.6k
技術的負債の返済は、AI時代の複利で効く投資 — 経営としての意思決定とその遂行
curekoshimizu
1
2.3k
AI時代のコードレビューは人に向けるな、仕組みに向けろ
texmeijin
5
3.6k
contenteditable と日本語入力に向き合う
colorful12
0
190
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
330
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
330
The SEO Collaboration Effect
kristinabergwall1
1
590
Tell your own story through comics
letsgokoyo
1
1.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Typedesign – Prime Four
hannesfritz
42
3.2k
Abbi's Birthday
coloredviolet
4
10k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Intergalactic Javascript Robots from Outer Space
tanoku
273
28k
It's Worth the Effort
3n
188
29k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Transcript
テスト書きたいけど テスト書きたいけど 書けてないのは何でなんだぜ 書けてないのは何でなんだぜ 2024-07-19 PHP勉強会 神戸
自己紹介 堂薗 伸樹(どうぞの のぶき) @DPontaro 所属:スターフェスティバル株式会社 大阪在住 妻、男の子2人、犬 ゲーム開発 → Webアプリケーション 登壇経験あまりないので、緊張してます
今日話すこと テストって書いたほうがいいよね でも書けてないことが多々ある なんでだっけを掘り下げて書く意欲をあげていきたい
私とはじめてのテスト はい いいえ
BDDフレームワーク ソシャゲのwebview画面のテスト に導入されました 初めて触れたテスト behat
ユニットテストもしたことない メンテつらい メリットがわからない 結局書かなくなった 初めて触れたテスト behat テストに対しての第一印象はよくなかった
テストの目的、メリット はい いいえ
リファクタリング 振る舞いを変えずに、安全に変更できる 品質保証 バグの早期発見、修正 不具合の再現(回帰テスト) ドキュメンテーション テストコード自体が仕様の説明になる 設計の改善 テスタブルなコードを書くことで、結果的に良い設計になる etc...
なんで書かないの? メリットいっぱいじゃん?
なんで書けてないんだっけ? はい いいえ
(満足いくほど)書けてないのはなぜか 成功体験が足りていない 自動テストの環境が整っていない 時間がない
成功体験を積めていない 労力 < メリット を感じる場面が多くないのではないか 最初がbehatだったので余計に。 自動テストの環境が整っていない 仕組みによる強制がないので、書かずとも進行してしまう開発 そして仕込まれる不具合 時間がない 眼の前のスケジュールにアップアップで、実装と動作確認で手一杯
はい
じゃあどうしていこうね はい いいえ
時間がない 書かないと早くはならない 時間がかかるのは、道具が手に馴染んでいない アサーション モック やれることを知っていても細かい書き方覚えてなく、ググる、ジピる時間が出てきたりす る 書いて脳と手に刻み込む。
時間がない ユニットテストから慣れていこう AAAパターン テストダブル(スタブ、モック、etc...) 設計の原則も知っていこう(テストしやすいクラスを意識していく) S:単一責任の原則 O:オープン / クローズド 原則
L:リスコフの置換原則 I:インタフェース分離の原則 D:依存関係逆転の原則
はい
自動テストの環境がない つくろう!!! 新規に走り始めたり、まだ日が浅いプロジェクトはチャンス。 後になればなるほど構築はしんどくなる。今すぐやろう
自動テストの環境がない そうはいってもCIのワークフロー作ったことないです やったことないと心理的ハードル高いよね、わかる GitHub Actions とか GitLab CI とかでやれるよ だいたい似たような流れになるよ
ワークフローが発火する条件 コードのチェックアウト 環境セットアップ テスト用のenvファイル作成 依存ライブラリのインストール テスト実行 (必要に応じて)結果をどこか(slackとか)に通知
自動テストの環境がない claudeに聞いてみた。 ざっと大まかな流れはこれで作れるので、 あとは多少の試行錯誤で動かせるはず。 がんばれ。
自動テストはあるけど、メンテされてなくて壊れてる この場合、どうしたらいいかは私が聞きたい 一旦部分的に重要なやつだけ、テスト通すようにしていくとか・・・? テスト実行時に特定のテストや、ディレクトリだけ指定するのはできるので そうして徐々に時間をかけて改善していく レガシーコード改善ガイド、あたりを読むといい?(積読状態) たいてい密結合しまくったコードが大量でテストしづらい状態 テストのためにリファクタリングしたいが、テストがないので安全にリファクタリングで きないパターン そのあたりの取り組み方とかも書いてあったような気がする
成功体験 きっとちょっとずつ積まれてるはず。思い出して。 behatのことは一旦忘れて。 仕様の漏れに気づく テストパターンを考えているうちに、想定しきれてない箇所に気づくことができた。 境界値テストとかやってると、まれによく出てくる 本番で発生した不具合の再現をテストに書いておいた 後日、別の人の機能実装時にきちんとこけてくれて同様の不具合を未然に防げた。 細かい修正はサクサク回して手早く動作確認できる phpunitだと、--filter
とか --group でローカルでは特定のテストだけ指定してサクサク 回したりしてる やってるうちに、きれいなクラス設計も見えてくるよ
成功体験 書いたら褒める!! 他人も褒める、自分も褒める、何回でも褒める テストを書くあなたは偉い!!!
ということで宣誓 引き続きやっていって呼吸するようにテストかけるようになります ただ量産するでなく、費やした労力に見合った結果を引き出せるテスト を作成できるようになります。
ご清聴ありがとうございました もっとテスト書いていきます はい