「僕ら」のテストに対する向き合い方

Transcript

1. 「僕ら」のテストに対する向き合い方 golang.tokyo #37 2024.11.20
2. 自己紹介 Sugar Sato (@satoIsSugar) • 2023年 BuySell Technologies入社 • 基盤チーム所属(Portal/Account/Approval) PjM ◦ アソシエイトマネージャー • Go / Angular / Serverless ◦ Go歴: Go 年目くらい • 熱帯植物 ◦ ビカクシダ • 猫 ◦ Lambda (♀ 2才)
3. プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 リユースに必要なすべての機能を提供する 「リユースプラットフォーム Cosmos」の開発が進行中です。 Cosmosを活用して、バイセルグループ全体での業務効率改善やデータドリブン経営の深化を目指しています。 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理 販売 多様なチャネルで収益最大化 CRM -顧客対応- 買取種別に応じた最適なシステム構築 Visit -訪問買取 - Store -店舗買取 - Promas -商材マスタ - Appraisal -専門査定 - Stock -在庫管理 - EXS -販売管理 - Core -会員管理- Portal -データ利用- Pocket -データ基盤- 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 ：基幹システム
4. 本題に入りまして、、、 「みんなテストは好きか〜？」
5. 好きだ〜🙌 好きじゃないぞ〜！ 正直どっちでもない ど ち らか とい え ば 好 きか も テストこそ正 義 ！ 逃げられない戦いがそこにある できることなら逃げたい カバ レ ッジ ！ カバレッジ！ mock!! testable!! カ バ レ ッジ ！ カバレッジ！ そ の 術 は オ レに 効 く テ ス タ ブ ル モック！ モック！ 0!! C1!!
6. ということで、今日は テストにどう向き合っているか話します
7. • 「僕ら」 = 「自分のチーム」 ◦ 限定的な話 ▪ プロダクトによって向き不向きがある ◦ 取り組み話が多め • WebAPI の Go にまつわるテスト話 ◦ OnionArchitecture の情報少し ⚠⚠⚠ 注意 ⚠⚠⚠
8. アジェンダ テストの基本方針 01 まとめ 02
9. テストの基本方針
10. • ざっくり4つを実施 ◦ カバレッジ目標を明確に定めない ◦ mock は「なるべく」使わない ◦ TDT + AAA パターン ◦ テストにも linter を！ テストの基本方針
11. カバレッジ目標を明確に定めない
12. メリット • 盲信的に数値を追うことだけをしなくて済む ◦ 「薄い」テストをなくせる ▪ OnionArchitecture の入出力だけするコード ▪ mock しか通さないテスト ◦ 数値以外の明確な理由があるなら納得 • 優先度の高い機能開発 ◦ 適切なリソース配置
13. • ライブラリ等のアップグレードを気軽にできなくなる ◦ テストで動作保証 ❌ ◦ 障害につながる可能性 ⤴ • チーム間のテストに対する認識のズレ ◦ 「十分なテストとは」 ◦ 「特定のファイルだけテストがないのは何故」 • コード変更時のリスク デメリット
14. カバレッジ測定方法 • 手順 ◦ go test ▪ coverprofile 生成 ◦ go tool cover ▪ html 生成
15. 出力されたカバレッジファイル
16. カバレッジ目標を明確に定める場合 • 70 ~ 80%くらいが良さそう かも ◦ カバレッジの目標値は何%にするべきなのか？ ▪ 注) 元記事内の参照元リンク切れ ▪ 「テスト完了条件ではない」 ◦ Code Coverage Best Practices ▪ 60%: acceptable ▪ 75%: commendable ▪ 90%: exemplary
17. カバレッジの可視化 • 予算あり: codecov, coveralls ◦ GitHub Actions ◦ goveralls • 予算なし: k1LoW/octocov ◦ GitHub Actions ◦ 公開 ▪ GitHub Pages にホスト ▪ 認証あり静的ホスト (S3 / GCS)
18. k1LoW/octocov • tbls などでも有名な k1LoW さん • 個人的に愛用🙏 • 手順 ◦ .octocov.yml 作成 ◦ GitHub Actions ▪ go test ▪ go tool cover ▪ k1Low/octocov-action
19. mock は「なるべく」使わない
20. mock を使うメリット • カバレッジの担保しやすさ • テスト実行時間が短くなる • 依存するリソースを用意しなくていい • 簡単な動作確認ができる ◦ レイヤ毎の入出力 ▪ usecase ←→ repository
21. • 想定するシナリオをテストしづらい • 依存サービスのバージョン互換性を保たない • ライブラリの習熟 ◦ gomock ◦ mockery ◦ moq mock を使うデメリット
22. • usecase テストがメイン ◦ データ永続化(repository)で複雑 なクエリがある ▪ mock を使用するならレイヤ毎 にテストをする • 実装コストに見合わない ◦ どうしても必要なら testify で mock を追加する その上で mock を使わない理由
23. mock を使う線引き • 「なるべく」使わないスタンスは変えない ◦ その上で ▪ 依存サービスの挙動が重要でない ▪ エッジケースの再現をしたい ▪ 外部 API のリクエストがある • dockertest や testcontainer でリソース準備が大変 • httptest をつかう ▪ etc…
24. TDT + AAA パターン
25. • Table Driven Testing ◦ データとロジックを分離 ◦ 冗長性の排除 ◦ 新しいテストケースの追加 ◦ 入出力の期待値の理解 TDT
26. TDT • Table Driven Testing ◦ 分岐が発生してしまう ケースがある ▪ 正常・異常の返り値で エラーをアサーションする
27. AAA パターン • Arrange Act Assert ◦ TDT の課題をクリアさせる ◦ 今年の GoConf でも同じ考えを...！ ▪ Table-driven testing に縛られないGoのテストパターン
29. テストにも linter を！
30. テストにも linter を！ • 以前の発表 (golang.tokyo #35)
31. golangci-lint の適用 • チームで運用する golangci-lint の向き合い方 ◦ 「テストコードもプロダクションコード同様に扱い品質を保ちたい」 ◦ 「どうしても ignore ルールを追加したい時はチームで相談する」
32. 以上が 「僕ら」の実施していることです 🙌
33. まとめ
34. まとめ • カバレッジに明確な目的をもたす • テストを簡潔にすることをめざす • 方針を都度変えていくことも大事 ◦ 全部は話せていない ▪ fixture ▪ e2e ▪ testify を使う理由 ▪ 失敗例
35. テストに秩序を！
36. Thank you
37. 引用 • https://sgash708.github.io/hbd-go/cover.html#file0 • https://qiita.com/odekekepeanuts/items/d02eb38e790b93f44728#%E3%82%AB%E3%83%90%E3%83%AC%E3%83%83%E3%82 %B8%E3%81%AE%E7%9B%AE%E6%A8%99%E5%80%A4%E3%81%AF%E4%BD%95%E3%81%AB%E3%81%99%E3%82%8B %E3%81%B9%E3%81%8D%E3%81%AA%E3%81%AE%E3%81%8B • https://testing.googleblog.com/2020/08/code-coverage-best-practices.html • https://speakerdeck.com/sgash708/timudeyun-yong-suru-golangci-lint-noxiang-kihe-ifang?slide=45 • https://about.codecov.io/blog/getting-started-with-code-coverage-for-golang/ • https://docs.coveralls.io/go • https://github.com/mattn/goveralls • https://github.com/k1LoW/octocov • https://speakerdeck.com/abekoh/table-driven-testing-nifu-rarenai-gonotesutopatan?slide=12