テスト書いてますか？そのテストは動いてますか？そのテストは他のメンバーに伝わりますか？/ PHPerKaigi-2023-after-event

PHPerKaigi-2023-after-event LT資料

Transcript

1. テスト書いてますか？ そのテストは動いてますか？ そのテストは他のメンバーに伝わりますか？ DateTime: 2023/04/26 At: PHPerKaigi2023アフターイベント 1
2. 自己紹介 • yuya.miyazaki ◦ @sucalul in twitter, github • 所属 ◦ 株式会社PR TIMES ◦ 2022年4月〜現在 ◦ 料金チーム ◦ 新卒2年目 • 職業 ◦ バックエンドエンジニア ◦ PHP/Go 2
3. 料金チーム • PR TIMESの料金システム周りを改善 ◦ 請求を立てる ◦ プランの変更・予約 ◦ 請求情報を見れる ◦ など請求が関わる系はまるっと全部 • 過去のコードも参考になるが、arrayがいっぱい、テストはない、ドキュメントもない、 料金周りに詳しい人はいるが、エンジニアではない 3
4. テスト書いてますか？ • Unitテスト • E2Eテスト など • 実装よりもテストを先に書く • 実装しながらテストを書く • 実装と同時ではないが、リリースまで には書く • 書かない ???「テスト書かないとか（ry」 4 *弊社のライオンデーの紹介をしました。 slackの画像なので削除。 （ライオンデー：みんなでテスト追加する日）
5. そのテストは動いてますか？ • CIが回っている • PRを出すタイミングで全てのテストを”必ず”回している • 不定期にせいよ、誰かが手元で回している • 作られたっきり動いていない・メンテナンスされてない など 5
6. そのテストは他のメンバーに伝わりますか？ • （ある程度そのドメイン知識がある人、これから学ぼうとしている人向け） • 関数名、データプロバイダを読めばある程度わかる • テストコードをちゃんと読まないとわからない・読んでもわからない 6
7. テスト書いてますか？ • これはある程度初期から（Unit、E2E）書くようになっていました • 手動での検証がめんどくさい • テストポチって押せば全部やってくれるのは楽 7
8. テスト書いてますか？ • Unitテストのカバレッジは？ ◦ 想定しうる異常系のパターンは全て満たしている？ • 縦に限らず横は？ ◦ plan_id: 1, 2 ◦ 想定しうる全てのケースを満たしている？ 8
9. テスト書いてますか？ • Unitテストのカバレッジは？ ◦ カバレッジを見る • 縦に限らず横は？ ◦ PdMと話したりして色々なパターンを考慮する ◦ プラン1からプラン2は変更できるけど、プラン2からプラン3には変更できないと か ◦ テストがでかくなっちゃう！！ ◦ classを切ればよくて、「プラン1から変更のパターン」「プラン2から...」 9
10. そのテストは動いていますか？ • CI回そう 10
11. そのテストは他のメンバーに伝わりますか？ 元々 • 誰にも伝わらないテストを書いていた ◦ 圧倒的英語力不足 ◦ 他の人は当然、後日見返した時の自分でさえもわからない ◦ テストを書く目的の一つとして、いずれリファクタする時のコストをいかに下げ れるかを考えておきたい →このままだと負債！！ 11
12. そのテストは他のメンバーに伝わりますか？ 改善 • 「どのような状況」、「期待される結果」を明記する • 日本語で書く ◦ >（日本語が母国語の人が多いので）テストの日本語化してテストの理解容易 性を向上させたり、そのテスト結果をドキュメント化できるかなどを試していま す。 ◦ https://developers.prtimes.jp/2022/10/31/tdd-workshop-2022/ ◦ エンジニア以外にも伝えやすい・共通言語を作るきっかけになる 12
13. そのテストは他のメンバーに伝わりますか？ • 例1. プランを予約するAPI ◦ before ▪ testMissingCompany ◦ ◦ ◦ after ▪ test_存在しない企業の時_プラン予約に失敗すること 13
14. そのテストは他のメンバーに伝わりますか？ • 例2. プランを予約するAPI ◦ before ▪ testNotTomorrowOrLater ◦ ◦ ◦ after ▪ test_適応中のプラン終了日よりも前の日付がプラン開始日として選択さ れている時_プラン予約に失敗すること 14
15. まとめ • テストを書こう！動かそう！人に伝わるものにしよう！！ • リファクタリング・機能改善する時にあなたはいないかもしれない！後世にテストを 通して仕様を伝えよう！ 15
16. アフタートーク Q：これからテストを追加していくのですが、どのように進めるのがいいですか？ A：まずは小さくて、inputとoutputがわかりやすい関数から入るといいと思います。 または、バグ修正のタイミングで、起きたバグをテストコードで表現した上で、それを直し て、テストが通ることを確認することもいいと思います。
17. アフタートーク Q：今動いているけど古いコードに対しても書いた方がいいですか？ A：テストをかけるなら書いた方がいいですが、時間もなければそもそもテストをかける状 態かどうかも怪しい（どんなデータを扱っているのかわからない、その他の理由もある） 場合もあると思うので、まずは新しく実装したコードや、バグ修正のテストコードから書き 始めるのがいいと思います。
18. アフタートーク Q：どうすればみんなテストを書いてくれるようになりますか？ A：僕は自分が書いたコードを手でぽちぽち確認するのはめんどくさすぎるのでテストを 書いている節があります。もちろん必要な時にはぽちぽちします。（まさか書いたコード を動作検証せずにPR出してないですよね？） また、コードが想定した振る舞いをするか、他の人に証明するためでもあります。
19. アフタートーク Q：どうすればみんなテストを書いてくれるようになりますか？ A：リファクタリングする時に楽です。一発で綺麗なコードは書けないので、何回かリファ クタリングします。その時に役立ちます。 チーム全体で品質を担保していく意識は大事で、エンジニアができるアプローチとして、 テストコードを書くというのがあると思います。
20. アフタートーク Q：CIを導入しようと思っています（質問ではないですが、話題に上がったので） A：早めに導入することをおすすめします。毎回全部のテストを”必ず”回す人なんていな いですし、回されないテストは腐っていくだけです。自動で回る環境を整えておきましょ う。
21. アフタートーク Q：CIが毎回赤いですが、上の人に無視しろと言われました（質問ではないですが、話題 に上がったので） A：失敗しているテストを直すか、実装を直すか、そのテストを消しましょう。そのような状 態だと何がコケてるとか毎回みないと思います。もしいつもと違うコケ方をしても「赤く なった、いつも通り！無視無視！」と思い、インシデントを起こすだけです。非常に不健 全な組織です。常にグリーンである状態を当たり前に思ってください。