Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JJUG_CCC_2024 プロダクトが変われば、テストも変わる

mashi
October 27, 2024
870

JJUG_CCC_2024 プロダクトが変われば、テストも変わる

mashi

October 27, 2024
Tweet

Transcript

  1. 1. テスト実行の遅さ: ◦ 全レイヤを通過するテストが多いため、1回のテスト実行に長時間を要する。 2. バグの検出難度: ◦ インテグレーションテストでは小さな変更による影響を特定するのが困難。 3. メンテナンスの複雑さ:

    ◦ テストデータ準備が複雑で、システムの変更に応じた更新が大変。 当時の自動テストの状況 やり方:DockerでPostgreSQL・Spring bootを起動しWeb APIのリクエスト・レスポ ンス・データベースの状態をまるっとテスト
  2. すべてインテグレーションテストで行っていた - 正しい動作 - リソースが見つからない - ユーザが入力したSO個数のバリデーション(マイナスを入れられない) - 付与されているSO個数からユーザが入力したSO個数を引くときのバリデーション こんなイメージ

    すべてのケースが実データベースを通しているので遅い 各種テストケースごとのテストデータを用意するのがめっちゃ大変(CSVで管理してい るので静的解析がきかせにくく、テーブルスキーマが変わったときにつらい
  3. プラスして、テストの検証方法による分類 1. 出力値ベーステスト ◦ 特定の入力に対する関数やメソッドの出力(戻り値)を検証 ◦ 例:メソッドの戻り値を検証する 2. 状態ベーステスト ◦

    操作後のシステムやオブジェクトの状態を検証 ◦ 例:テーブルに新しいレコードが追加されたことを確認する 3. コミュニケーションベーステスト ◦ テストダブルを使用して、クラス間のメソッド呼び出しを検証 ◦ 例:サービスクラスがリポジトリのsaveメソッドを正しいパラメータで呼び 出していることを確認
  4. おまけ:コード自体を変えていく - どこからでも呼ばれていたSetterを廃し、カプセル化する - ファクトリメソッドを用いてコンテキストにあった初期化を行う - 複数個で意味があるものは、ファーストクラスコレクション - Spring Data

    JDBCの集約機能を使い、データの整合性を取る - Record Classを積極的に利用、ボイラープレートをなくしイミュータブルに - ⭐ここでもjiltが輝く! - 手続き的なif文をやめ、switch式で全域関数にしていく
  5. 1. テスト実行の遅さ: ◦ 全レイヤを通過するテストが多いため、1回のテスト実行に長時間を要する。 2. バグの検出難度: ◦ インテグレーションテストでは小さな変更による影響を特定するのが困難。 3. メンテナンスの複雑さ:

    ◦ テストデータ準備が複雑で、システムの変更に応じた更新が大変。 当時の自動テストの状況 やり方:DockerでPostgreSQL・Spring bootを起動しWeb APIのリクエスト・レスポ ンス・データベースの状態をまるっとテスト
  6. 1. テスト実行の遅さ ◦ 単体テストが増えたことでローカルで高速にイテレーションを回せるように 2. バグの検出難度 ◦ パラメタライズテストで網羅率UP 3. メンテナンスの複雑さ

    ◦ 各レイヤごとにテストを書けるようになった ◦ ビルダーパターンの導入、LLMの利用でデータ準備のコストも圧縮 今の自動テストの状況 方針:レイヤごとにテスト方針を定め、テストサイズとテストスコープを小さくする
  7. 早くフィードバックを得られることが自動テストのよさ 1. DBアクセスを伴わないテストならローカルで一瞬でわかる ◦ ガシガシ書いてガシガシ直す ◦ 手を動かしたほうが理解が早くできることもある 2. 遅いテストはそれだけで設計を歪ませる ◦

    テストの待ち時間が長いことで、後回しにされる「ちょっとした改善」 ◦ 高速なテストにすることで「すぐ直す」をくせにできる ◦ (これあるあるだと思います)