自動テストを書きながら気にしていること

この記事は、Uzabase Advent Calendar 2023の17日目の記事です。

1.はじめに

この記事は、私たちがいつもチームで自動テストを書いているときに、どのようなことを考えているかを思いつくままに紹介するものです。私たちのチームでは、特定の誰かだけがテストを考えたり書いたりすることはありません。いつもみんなで考え、みんなで書きます。みんながテストを大事にしています。

2.開発の流れ

私たちのチームでは、受け入れテスト駆動開発(ATDD)を採用しており、ユーザーストーリーの単位で開発のサイクルを繰り返しています。原則、作業はペアで対話しながら行います。

大まかな流れは、例えば以下のようなものです。(記事にするために、ある程度詳細を省いています)。
・ローカルPCで開発環境を準備する。
・最初に、ユーザー視点でのテスト(受け入れテスト)を考え、自動テストとして記述する(画面がある場合は、画面を操作する形のテストになります)。
・上記のテストが通る(テストに合格する)まで、段階的にテスト→設計→実装のサイクルを繰り返す。詳しくは過去のテックブログを参照してください。
・masterブランチにpushしてCIを実行する(過去に記述したテストが、すべてリグレッションテストとして実行される)。
・CIが通ったら開発環境に自動的にリリースされるので、何か(人間が見て初めて気づくような)問題がないか、人の目で簡易的に確認する。
・本番環境に対してリリースする。

3.自動テストを書きながら気にしていること

暗黙的な条件はないか

例えばログインするユーザーの種類によって期待する結果が異なるのであれば、ユーザーの種類を明示したうえでテストを分けます。操作手順に明示的に表現されづらい暗黙的な条件はそれなりにあることが多いので、特に、受け入れテストを考える際は慎重に進めます。

ユーザーストーリーをもっと分けられないか

例えば検索結果を一覧表示する機能を作るとして、最初のリリースではソート順は無視してよいかもしれません。もしそれで顧客に最初の価値が届くなら、ソート順を別のユーザーストーリーに分割する相談をします。

特定の要素が無かったらどうなるのか

ここでは「データ」を例に書いてみます。誰かの名前を表示する機能を作るとして、名前のデータは必ずしもリクエスト先から返って来ないかもしれません。そもそも通信が失敗するかもしれません。そのような場合にソフトウェアはどうふるまうべきなのかを考えます。
数値を扱うなら、特に「0」は特殊な仕様になる場合が多いので優先的に考えたいです(例えば、検索結果が0件の場合に限り「検索結果はありません」のメッセージを表示するようなことがあります)。

似たような言葉はないか

今から書くテストで使おうと思った言葉が、すでに別のテストで使われている場合があります。両者が同じ意味なら特に問題ないのですが、異なる意味で同じ言葉を使いたくなった場合は問題です。言葉を分ける方向で話し合い、場合によっては既に書かれたテストを書き換えます。

具体例な値を言い換えられないか

例えば文字の色を確認する場合に、「#ff0000」と書くと、カラーコードを読めない人に伝わりづらい可能性があります。「赤色」とすると、カラーコードを読めない人にも伝わりそうです。更に、「警告を示す色」などの表現に置き換えられると、意図も表現できそうです。(後者になるほどよいと言いたいわけではありません。状況によります。)

いま書いているテストで扱うべきことか

ソフトウェアのある部分ごとに、その部分が担うべき責務に対するテストを書き、それ以外のテストは書かないようにします。計算のテストは計算の責務を担う部分のテストとして書き、出力のテストは出力の責務を担う部分のテストとして書きます。ユーザー視点でのテスト(受け入れテスト)として、たくさんの組み合わせのテストを網羅的に書きたくなったとしたら、何かが間違っているかもしれません。機械的に判断できる場合もあればそうでない場合もあり、迷った場合は各ペアの手を止めて、みんなで議論の時間を設けたりします。

何が同じまとまりで、何が同じまとまりでないのか

例えば「企業が所属する国が日本である場合は、項目Aを表示する」という要件があった場合に、「企業が所属する国が日本以外である」一群はひとつのグループにまとめても良さそうです。しかし実装をよく確認すると、「企業が所属する国がフランスである場合は特別な処理をする」といった既存の仕様が隠れている場合があります。この場合、日本とフランスとそれ以外の任意の国の3つのデータでテストをしておかないと、問題を見逃すかもしれません。

極端な状態ではどうなるのか

例えば、データ量が多いページを開こうとした場合にどのようなふるまいをするべきか、そもそもソフトウェアが耐えられるかといったことを気にします。画面にローディング中であることを示すアニメーションを表示したり、内部のロジックをより高速なものに置き換えたりすることを検討するきっかけになります。

ペアで共通認識が持てている(と思えている)か

この項目は、テストそのものではなくコミュニケーションについての話題です。例えばペアの相手が何かを懸念していそうな場合に、こちらから質問します。ペアの相手に伝わっていないと感じた場合、もう一度説明します。ペアの相手が納得していないと感じた場合、手を止めて話し合います。

4.おわりに

こんな感じで日々いろいろ考えながら、チームみんなで毎日テストを書いています。「2.開発の流れ」に書いたサイクルをひたすら繰り返しているので、ともすればすぐ飽きてしまいそうに見えるかもしれませんが、具体的な状況は毎日変わるので常に新鮮な気持ちでテストを考えることができます。個人的には、いわゆるプロダクトコードを読むことに対する苦手意識が強く、大変だと感じることもあります。しかし、その大変さを乗り越えた都度、より良いテストが書けるようになっている実感もあります。これからもテストを書くことが楽しみです。