Android Test 概要

現状のJetpack Composeを採用した時のTestの選択肢を確認したい

テストの種類

ユニットテスト(単体テスト)

→クラス毎のテスト

• ローカルユニットテスト(Local Unit Test)
  • Android フレームワークを用いないテスト
  • Junit4がデフォルト
  • Kotlin Croutinesはkotlinx-coroutines-test
• インストゥルメントユニットテスト(Instrumented Unit Test)
  • Android フレームワークを用いるテスト(Room, Retrofit)
  • 実機は使用しない
  • AndroidXテストフレームワーク（デフォルトで入っている）
  • MockK(Kotlin Coroutinesをサポートしている)
    • モック
      • 戻り値が特にないものの挙動を確認する
    • スタブ
      • 事前定義した任意の値をテスト対象に与える
    • スパイ
      • スタブの上位互換でモックとスタブの役割を兼用する
    • フェイク
      • 実際のコンポーネントと同等のコンポーネント
    • ダミー
      • テスト対象内でなにもしませんが、コンパイルなどの都合上、用意する必要があるもの

必要な観点

1. テストケースを減らすための工夫をする
   1. 同値分割(同じ挙動をする値を一つのグループとする)
   2. 境界値
   3. 単項目チェック(if文の条件が複数ある場合に順番による絞り込み)
2. テストカバレッジ(以下のどれくらいテストを書けばいいのかを意識)
3. 明確なテスト名
4. 異常系のシナリオ
5. 依存関係の管理(上記のテストダブルを使用する)

インテグレーションテスト(結合テスト)

• 確認することはデータフローの確認、API呼び出しの検証、ローカルデータベース、コンポーネント間の連携
  →あくまでもシステムの連携を確認する
  ツールはユニットテストと変わらない

必要な観点

1. 主要なユースケース(サービスの根幹)をカバーできているか
2. エラー処理と例外
3. セキュリティ
4. パフォーマンス

UIテスト

→Jetpack ComposeにはTest APIがある

スクリーンショットテストも公式である(https://developer.android.com/studio/preview/compose-screenshot-testing)

必要な観点

1. 目的を整理する
   1. 既存機能のバグを予防したいのか
   2. リリースに必要な日数を短縮したいのか
   3. テストコストの低下
2. 自動化する範囲を決める
3. CI環境を構築する

どれくらいテストを書けばいいのか

全体のテストの理想の割合

ユニットテスト　→　70％

インテグレーションテスト　→ 20％

UI Test → 10％

理想のcoverage(どれくらいテストを網羅しているか)

70%〜90%くらいの間が多いらしい