Zenn
🌟

モバイルでできそうなテスト駆動開発のアイデアを思いついたので聞いて欲しい

2024/05/15に公開
Android
iOS
idea

モバイルアプリを開発しているプロジェクトの課題を解決するための 1 つの施策を考えついたので、メモしておきます。

前提・背景

プロジェクトで以下のような課題がありました。

  • 画面仕様書を定義して開発やテストを進めているが、エンジニアが画面仕様書の細部まで読み込めていない場合がある
  • 単体テストコードを書いているものの、デグレの防止、コードの各レイヤーの責務の整理、仕様の妥当性見直しなどのきっかけとなっている実感が薄い
プロジェクトでの画面仕様書の例

プロジェクトにおいて画面仕様書は、デザインと各 UI のアクション、アクションの発動条件が記載されたものになっています。

デザイン

条件とアクション

  • (1)をタップした際
    • 投稿に成功した場合
      • 投稿画面を閉じる
    • 投稿に失敗した場合
      • トーストで、「投稿に失敗しました。時間を空けて再度お試しください」と表示する

また、テスト駆動開発という考え方があります。
テスト駆動開発は、テストコードを先に書き後からプロダクトコードを書くような制約を儲けたりすることで包括的なテストコードを得て、それによりリファクタリングしやすく品質の高いコードを得る開発手法です。

モバイルの開発においては、UI や UI ロジックのテストを書くのが難しかったりメンテナンスコストがかかりやすいため、テスト駆動開発が難しいという感覚がありました。

一方で、振る舞い駆動開発という考え方もあります。

https://www.tutorialspoint.com/behavior_driven_development/behavior_test_driven_development.htm

振る舞い駆動開発は、テスト駆動開発の考え方をベースとしつつ、テストケース構築の切り口をユーザーから見えるシステムの振る舞いに着目する方法です。

振る舞い駆動開発の考え方を導入することで、現在のモバイルプロジェクト課題を解決できるのではないかと着想を得ました。

アイデアの概要

コード実装時、以下を必須の作業として進めるようにします。

  • 画面仕様書における条件に応じた表示やアクションに応じた UI の挙動に対し、画面ロジック部分のみをテストコードとして定義

導入しようとしているプロジェクトでは、今までテスト駆動開発などは導入していません。
そのため、開発のやり方のギャップが大きくなりすぎないよう、テストコードを先に書いてプロダクトコードを後から書くなどの細かいタイムボックスの制約は一旦設けずに導入することを検討しています。

詳細

テスト対象

実装する際に参照する画面仕様書における、条件に応じた表示やアクションに応じた UI の挙動とします。

これらの条件全てに対し、条件 1 つに対して 1 つのテストコードが対応するように書きます。

テストコード実装時の方針

1. UI はテストせず、かつスモールテストの範囲とする

安定性や速度を高めるための方針です。

スモールテストとは、1 つのマシン内の 1 プロセス内で実行が完結するような高速なテストのことです。
Google Testing Blog で詳細が紹介されています。

https://testing.googleblog.com/2010/12/test-sizes.html

クラスアーキテクチャーの各レイヤーにおける、本物(Real Object)やダミー(Fake Object)などは以下の図のように想定しています。

この内容が UI ロジックレイヤーから出力されれば、UI は正常に表示されるだろう、という前提に立ち、UI ロジックの入出力を確認します。

また、スモールテストなので、1 つのプロセス内で完結するようにします。
つまり、API や DB、キーバリューストアは本物を利用せず、モックを使います。

ただし、API、DB、キーバリューストアのレイヤーのモックを利用すると、依存関係によっては Android で実機テストにする必要が生じます。
そのため、リポジトリのレイヤーをモックにする方が良さそうです。

UI ロジックに近い場所をモックしすぎると、UI ロジックに紐づくアプリの動作のテストにならないため、それ以外の部分は全て本物を使います。
また、モックしすぎるとホワイトボックステストに近くなり、仕様変更やリファクタリング時にテストコードが壊れやすくなります。

2. 画面仕様書の分岐を全て網羅する。また、それ以上のテストはしない

必要十分にテストケースを網羅するための方針です。

テストケースが多すぎるとメンテナンスコストは膨れ上がっていくので、特に、書かれていない分岐のテストは書かないという方向の意識が重要です。

考えられるメリット

以下のようなメリットが考えられます。

  • 画面仕様書をテストコードに起こし、そのテストコードをレビューする機会が増えることで、画面仕様書に対する理解度の属人性が減少する
  • 動作確認の再実行を容易にし、リファクタリングの心理的ハードルが下がる
  • UI ロジック周りでテストコードを実装することで、テストコードを実装するために UI と UI ロジックの責務分離が正しくできていない箇所が是正されるなどのアーキテクチャーの見直し機会が増える
  • テストコードのレビューはプロダクトコードのレビューより難易度が低いことも多いため、異なる技術スタックのメンバーで相互レビューできる
  • 包括的な自動テストが実装されることに繋がり、エンジニア・QA が品質に対して根拠ある自信を持てる

考えられるデメリット

また、以下のようなデメリットが考えられます。

  • 今まで実装していなかった部分のテストコードを実装するようになるため、開発工数が掛け算で増えていく
  • UI ロジックのテストのために、アーキテクチャーの責務分離方針を事前に整備する必要があるかも
  • テストコードの実装がしやすいよう、画面仕様書の書き方を工夫する必要があるかも

最後に

まだ実践していないので、机上の空論の可能性もあります。

実験中ですので、続報をお待ちください。

GitHubで編集を提案

Discussion