懺悔-テストを何一つ書いていませんでした-

俺の懺悔2022

Transcript

1. 懺悔 - テストを何一つ書いていませんでした- 2022/12/20 マネーフォワード フロントエンドLT 大会2022
2. 今回話すこと ・フロントエンドのテストを書かなかったことによる愚行のお披露目 ・それによって自分の身に起こった悲劇 ・それを踏まえてどうアプローチしたか ・今後 話すこと ・具体的なコードやテスト用ライブラリの使い方 ・バックエンド向けのアプローチ 話さないこと
3. 名前: Ibuki Yoshinaga 誕生日: 2001/02/24 Twitter: @__GGEasy フロントエンド寄り
4. ゲシピ株式会社に転職しました🎉 e スポーツに関するEdTech 事業を展開しているまだ小さなスタートアップ 高校生の頃からここでインターンや業務委託のエンジニアをしていた
5. 今回の発表内容に関連するプロダクト ・主に小学生~ 大人向けの英会話レッスンを提供するtoC サービス ・ネイティブスピーカーの講師陣とFortnite やマイクラを遊びながら、英会話 を教えてもらえる ・レッスン中の報告や要望、雑談などはできるだけ英語でコミュニケーショ ンを取る ・コロナ禍で小学生のゲーム時間が増えたことから誕生した e スポーツ英会話
6. 使用している主な技術 ・Next.js ・styled-components ・Recoil ・Storybook フロントエンド ・Nest.js ・Prisma ・OpenApi バックエンド ・Heroku インフラ ・GitHub Actions CI/CD
7. 皆さんはこの名言を知っていますか？
9. この男はテストを書かずに人生を歩んできた
10. ~~~ ここから言い訳~~~
11. 時間がなかった 当時の開発組織 (~2022/08) CTO( 設計 + 他プロダクト + マネージメント) フルタイム ワイ( 設計 + 開発) 他2 人( 設計 + 開発) 業務委託 ・CTO への技術的な相談が気軽にでき、稼働時間に対してもかなり自由度が高かった ・業務委託中心で開発を回す仕組みが出来ており、裁量も大きかった ・スタートアップなので毎日が新規開発 よかった点 ・社内向け管理画面が多かったので、バグっててもごめんなさいで済んでしまった ・業務委託が多いので、稼働できない月はリソースが圧迫していた ・仕様変更が結構あるので、テスト書いても変更された部分は消えるしなぁ... という気持ち ・結果的にテストや保守業務よりも新規開発に充ててしまった 言い訳
12. 2022/09 、遂にゲシピ社初のエンジニアとして転職 ワイ「開発し放題やんけ！時間もいっぱいあるしな！」
13. どうなったか？
14. さらに時間がなくなった 現在の開発組織 (2022/09~) CTO( 設計 + 他プロダクト + マネージメント) ワイ( 設計 + 開発) フルタイム メンバー2( 設計 + 開発) メンバー3( 設計 + 開発) 業務委託 ・毎日が新規開発 + 開発スピードも上がった( 楽しい) ・これまでよりもサービスに愛着が湧いてきた( 可愛い) ・会員数も増えてきた( 嬉しい) よかった点 ・改修が怖くなった ・潜在的なバグ、新規開発によるバグが怖くなった ・動作確認が大変になった ・遂にユーザー向け画面の開発が本格化した 規模が大きくなるにつれて ...
15. ここで、あることに気がつく
17. 何故時間がなかったのか ・改修が怖くなった = 保守性が著しく下がっている ・潜在的なバグ、新規開発によるバグが怖くなった = 短期的な恩恵( 開発速度の上昇) は既にない ・動作確認が大変になった = 開発体験/ バグによるユーザー体験を大きく損ねる 長期的に見て、テストがないこと自体が何よりもの技術負債になりえる そして、これら全てに気を遣う時間こそが最も無駄な時間だった テストがない現状 ・改修時の視野をより限定的にできる = 保守作業をより楽に、バグに気が付きやすくなる ・規模が大きくなった場合でも、機能に対する動作保証をある一定のラインで担保できる ・長期的に見て、動作確認に費やしていた時間を全て開発に充てることができる = 視野を限定することで、これまで足りないと感じていた開発時間を結果的に増やすことができる テストがあるとどうか ・エラーが起こったことをいち早く察知する → Sentry やBugsnag などでのエラー監視 ・エラーが起こらないことを担保する → テストでの監視 視野を限定的にするには
18. アプローチ
19. 最低限から初めてみる ・テスト難しいや！一旦やめ！みたいなのは避けたい ・最初は雑魚狩りをしたい( 自己肯定感を上げるためにも) お気持ち ・コンポーネント/ 独自フックの最低限の動作確認 ・画面毎の挙動やSnapshot の確認 テストでやりたいこと 短期的な開発速度を落とさないことは必須。その上で一番困っている部分からテストを作り始める Sentry によるエラー監視も導入し、壊れたことに気が付きやすい状態にしていく テストの内容 ・React Testing Library Atom レベルのコンポーネントやHooks 単体から作り始 める コンポーネント /Hooks テスト ・Cypress 登録 → 初期設定ページくらいから作り始める 最初は正常系とバリデーションテストの2 種類を書く E2E テスト
20. 開発フローの見直し 開発開始！ 開発終了！ 開発開始！ 開発終了！ を繰り返していた これまで 開発開始！ 開発終了！ テストを書きます... 開発開始！ 開発終了！ テストを書きます... テストを書く時間を踏まえたスケジュールに調整 TDD なども考えたが、まずはとにかくテストに対するモチベーションを上げることを優先 これから
21. 現在どうなっているか PR 立ち上げ時に動作 ・eslint ・TS の型チェック 静的 ・React Testing Library 単体 / 結合 STG デプロイ時に動作 ・Cypress ・Storybook(Atom レベルだけ) UI ・Sentry での監視体制 ・他部署との連携による社内向け不具合報告フォームの設置 常時
22. まとめ
23. まとめとこれから ・テストを書いた部分の動作保証が担保されるように ・改修や仕様変更による調整が楽になった ・自分の中で保守業務に対するモチベーションが上がった ・テストを前提としたコードを考えるようになった まずは書き始めてみる、クオリティを求めるのは最低限が 揃ってからでいいという心構えを重要視する よかったこと・わかったこと ・現状クリティカルな部分に絞って作成しているので、全コンポーネント/ ページに対して適用したい ・業務委託含めたチーム全体にテスト文化を作っていく ・テストのカバレッジなどの目標を立てる ・a11y やパフォーマンス、ビジュアルリグレッションテストなども必要に応じて導入していきたい これから
24. 2023 年も頑張ります！ 副業も募集してるよ ... ！人が足りないよ ... ！