サイトアイコン プログラマー(PG)・システムエンジニア(SE)になるための入門講座

【保存版】単体テストの名前はどう付ける？自動化・静的解析に強くなるテスト名の付け方完全ガイド

pgse

【保存版】単体テストの名前はどう付ける？自動化・静的解析に強くなるテスト名の付け方完全ガイド

単体テストの自動化を進めていくと、多くのプログラマーやSEが必ず悩む問題があります。それが「テスト名に何を書くべきか」という問題です。

最初は「適当に動けばいい」と思って付けたテスト名でも、数ヶ月後には意味が分からなくなります。そしてテストが増えてくると、テスト名の品質はそのまま保守性や開発効率に直結するようになります。

私は過去に数千件の単体テストを保守するプロジェクトに関わった経験がありますが、最も作業効率に影響したのはコードよりもテスト名の分かりやすさでした。

この記事では、単体テスト自動化や静的解析を前提として、テスト名に何を書くべきかを詳しく解説します。

この記事を読むことで次のことが分かります。

単体テストの名前が重要な理由

単体テストの名前は単なるラベルではありません。

テスト名は以下の役割を持ちます。

つまりテスト名は開発者のためのドキュメントなのです。

特にCI環境で自動テストを回す場合、失敗したテスト名だけを見て原因を推測する場面が頻繁にあります。

このときテスト名が分かりにくいと調査時間が何倍にも膨れ上がります。

悪いテスト名の典型例

まずは悪い例を見てみます。

test1
testUser
checkData
正常系テスト
異常系テスト

これらの名前には共通の問題があります。

このようなテスト名では、自動テストが失敗した場合に原因を特定できません。

結果として「テストがあるのに品質が上がらない」という状況になります。

良いテスト名の基本構造

良いテスト名は次の3つの要素で構成されます。

つまり次の形になります。

【対象】_【条件】_【期待結果】

例えば次のような名前になります。

calculatePrice_数量が0_合計金額が0になる
login_パスワード誤り_ログイン失敗する
withdraw_残高不足_例外が発生する

この形式にすると、テスト名を読むだけで仕様が分かります。

筆者の体験談：テスト名改善で作業時間が半減した話

以前参加したプロジェクトでは、約3000件の単体テストが存在していました。

しかしテスト名は次のような状態でした。

testA
testB
pattern1
pattern2
errorTest

CIでエラーが出ると次のように表示されます。

pattern2 FAILED

これでは何が起きたのか全く分かりません。

結局、テストコードを開いて確認する必要がありました。

1件の調査に10分以上かかることも珍しくありませんでした。

そこでテスト名を次のように変更しました。

calculateFee_休日料金_100円加算される
calculateFee_平日料金_加算されない
calculateFee_未設定_例外発生

するとCIの表示がこう変わりました。

calculateFee_休日料金_100円加算される FAILED

この時点で原因の見当がつきます。

結果として調査時間は平均10分から3分以下になりました。

テスト名だけでここまで効率が変わることに驚きました。

自動化に強いテスト名の付け方

機械が読める名前にする

テスト自動化では機械処理のしやすさも重要です。

例えば次のような名前は問題があります。

ログインできることを確認するテスト

これは人間には分かりやすいですが長すぎます。

おすすめは次の形式です。

login_validUser_success

この形式は次のメリットがあります。

英語を使うべき理由

多くの現場では英語が推奨されます。

理由は次の通りです。

例えば私は以前、日本語テスト名を使っていたことがあります。

しかしログ収集ツールで文字化けが発生しました。

それ以降は英語に統一しています。

静的解析と相性の良いテスト名

静的解析ツールを導入すると、テスト名の品質もチェックされる場合があります。

例えば次のようなルールです。

例えば次の名前は避けた方が良いです。

calc_ok
usr_ng
dt_chk

代わりに次のように書きます。

calculatePrice_validInput_success
createUser_duplicateEmail_error

静的解析とテスト命名を合わせることでコード品質が安定します。

おすすめの命名テンプレート

現場で特に使いやすいテンプレートを紹介します。

Template1：Given_When_Then形式

Given残高1000円_When500円出金_Then残高500円

これはBDDスタイルの書き方です。

仕様書代わりになります。

Template2：メソッド中心形式

withdraw_insufficientBalance_throwException

最も一般的な形式です。

Template3：仕様書形式

ユーザー削除時_関連データも削除される

業務系システムで有効です。

テスト名を改善すると得られるメリット

メリット1：バグ調査が速くなる

例えば次の2つを比較します。

悪い例：

testError FAILED

良い例：

transfer_balance不足_error FAILED

後者ならすぐに分かります。

調査時間が短くなります。

メリット2：レビューが速くなる

レビュー時にテスト名を見るだけで仕様が分かります。

コードを読む時間が減ります。

メリット3：仕様漏れに気付ける

テスト名を書いていると気付きます。

例えば：

login_lockedUser_error

この名前を書いた時点で「ロックユーザーの仕様が必要だ」と気付きます。

これは実際に私が経験したことです。

応用編：さらに便利になるテスト命名テクニック

番号を入れない

悪い例：

test01
test02
test03

順番が変わると破綻します。

仕様IDを入れる

おすすめの方法です。

REQ123_login_invalidPassword_error

仕様書と紐づきます。

保守が楽になります。

テスト名を仕様書として使う

例えば次のように並びます。

login_validUser_success
login_invalidPassword_error
login_lockedUser_error
login_emptyPassword_error

これだけで仕様が見えます。

これを私はテスト仕様一覧として使っています。

最も重要なルール：第三者が理解できる名前にする

最も重要なのは次のルールです。

テスト名だけ読んで内容が分かること

未来の自分は他人です。

半年後には忘れています。

だからこそ説明的な名前が必要です。

まとめ

テスト名には次の要素を書くべきです。

おすすめ形式は次です。

対象_条件_期待結果

テスト名は単なる名前ではありません。

テスト名は自動化時代の仕様書です。

良いテスト名を付けるだけで次の効果があります。

もし単体テストを自動化するなら、まず見直すべきはフレームワークではありません。

テスト名です。

ぜひ一度、現在のテスト名を見直してみてください。

モバイルバージョンを終了