Zenn
📖

【リーダブルコード】テストコードも「読みやすさ」が命

に公開
Java
リファクタリング
リーダブルコード
コード最適化
読みやすいコード
idea

✅ テストコードも読みやすくなければ意味がない

テストコードはただ「動く」だけでは不十分です。
他の開発者が見ても直感的に理解でき、簡単に修正・追加できることが重要です。

もしテストコードが煩雑で大きく、理解しにくいものであれば、次のような問題が発生します：

  • コードの修正が怖くなる
  • テストケースの修正が面倒になり、新たなテストが追加されない
  • テストカバレッジが下がり、安心してコードを修正できなくなる

🔍 TDDに潜む罠：テストの副作用とテスト漏れ

TDD（テスト駆動開発）では最初にテストを作りますが、後から機能を修正したとき、テストコードも一緒に修正しなければならないという副作用が発生します。

特に、最初に書いた人以外が後から見ると、テストの意図やロジックを理解するのが難しく、必要な検証を見落とすリスクも高まります。

🧪 テストコードも綺麗に書かなければ、後で手が出せなくなる

例として、ユーザーアカウント関連のテストを初期に以下のように書いていたとします：

✏️ 改善前のコード（Java版）

@Test
public void signUpTest() {
    User user = new User();
    user.setUserId(UUID.randomUUID().toString());
    user.setPassword(UUID.randomUUID().toString());
    user.setName(RandomUtil.randomString(4));
    // その他の初期化...

    userRepository.save(user);

    Assertions.assertEquals(...);
}

これは動作的には問題ありませんが、ユーザー作成処理を関数に切り出した方が圧倒的に管理がしやすいです。

✅ 改善後のコード

public User fakeCreateUser() {
    User user = new User();
    user.setUserId("test-" + UUID.randomUUID().toString());
    user.setPassword("secure-password");
    user.setName("テストユーザー");
    return userRepository.save(user);
}

@Test
public void signUpTest() {
    User user = fakeCreateUser();
    Assertions.assertEquals(...);
}

このように関数で抽出しておくと：

  • 他のテストでも簡単に再利用可能
  • 登録仕様が変わっても関数一箇所の修正で済む
  • テストコード全体の行数も減り、見やすくなる

🧹 テスト後のクリーンアップも考慮する

時間が経つと、テストで作成されたユーザーアカウントが残ることに気づきました。
assertの後に削除処理を追加しても良いのですが、それも煩雑です。

そこでユーザーIDに "test-" を接頭辞として付け、全テスト終了後に "test-" で始まるアカウントを一括削除する仕組みを導入しました。

👁 見やすいデータ設計と入力値も大切

テストケースではロジックだけでなく、使用するデータも明快であるべきです。
例えば「1～100が正常」の場合、次のような境界値を使用するのが望ましいです：

int[] testValues = {0, 1, 100, 101};

最小限かつ意味のあるデータで、コードの網羅性と可読性の両方を確保するのが理想です。

🧠 書いているコードのテストを将来書くと想定すると…

今まさに書いているコードのテストを「将来書く」と意識した瞬間、自然とコードの構造にも気を配るようになるものです。
テストしやすい設計にすることが、結果的にコード全体を美しく、堅牢にします。

✅ まとめ：テストも第一級のコードである

  • テストコードも普通のコードと同様に**「見やすさ・再利用性・保守性」**が求められる
  • 簡潔で最小限の入力データを使い、境界値を意識する
  • テストのための共通処理は関数化し、メンテナンスコストを下げる
  • 後の修正や拡張のしやすさが、最終的な品質と効率を左右する

Discussion